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AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 

DEDICATED  TO  PEACE  WITH  SECURITY  THROUGH  DEFENSE  PREPAREDNESS 


Dear  Follow  ADPA  Member: 

Your  response  to  this  questionnaire  is  requested  to  help  us  identify 
problems  with  Technical  Documentation  in  the  defense  industry.  The 
Technical  Documentation  Division  is  proud  of  the  close  and  effective 
relationship  between  its  industry  and  government  members.  It  is 
through  this  relationship  that  we  can  identify  and  resolve  problems 
for  the  simplification  and  improvement  of  Technical  Documentation. 
Your  participation  is  essential. 

Please  take  a  few  minutes,  complete  the  following  questionnaire,  and 
mail  it  to: 

T.  L.  Golmis 
Hughes  Aircraft  Company 
Bldg.  604,  M/S  B-114 
P.  0.  Box  3310 
Fullerton,  CA  92634 


1.  What  feature  or  talk  given  at  the  1984  meeting  was  the  most 

informative?  _ : _ 

.  .  .  Helpful  to  you?  _ . _ 

2.  What  problems  are  you  having  that  you  would  like  to  see  resolved? 


3.  What  subjects  would  you  like  to  hear  discussed  at  the  1985 

meeting  to  be  held  in  Phoenix,  Arizona '(dates  to  be  determined). 


Your  answers  will  be  reviewed  by  the  TDD  Executive  Board.  Where  neces 
sary,  ad  hoc  committees  of  industry  and  government  members  will  be 
created  to  work  your  problems. 

Sincerely, 


T.  L.  Golmis 
Chairman, 

Technical  Documentation  Division 

TLG/cvc 

P.S.:  Additional  comments  and  suggestions  are  invited. 

j  ft  A.  •  •  -A  ' 

j  tor  '  - 


3SNJdXJ  lNdWNUJAOO  IV  (1  UlKIOII.I  1H 


AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 

DEDICATED  TO  PEACE  WITH  SECURITY  THROUGH  DEFENSE  PREPAREDNESS 


Founded  1919 


THE  MISSION 


THE  AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 


The  American  Defense  Preparedness  Association  exists  solely  for 
the  advancement  of  adequate  national  defense  of  the  United  States 
in  the  fields  of  weapons  technology,  production,  and  logistics. 

We  strive  to  improve  the  effectiveness  and  efficiency  of  the 
Government-Science-Industry  relationship  in  the  development  and 
production  of  weapons  and  weapons  systems.  Our  field  of  interest 
covers  all  ordnance,  armament,  weapons,  weapons  systems,  and 
related  equipment  for  the  Armed  Forces  of  the  United  States.  Our 
interest  also  includes  techniques,  processes,  and  materials  that 
have  wide  application  in  the  development,  production,  and 
logistics  of  weapons. 

Through  its  publications  and  meetings — national,  local,  and 
technical — the  Association  endeavors  to  educate  its  members  and 
the  public  on  problems  affecting  weapons  preparedness.  Our 
technical  divisions  provide  advice  to  Government  agencies  on 
weapons  technology. 

The  Association,  founded  in  1919,  is  a  non-profit  and  non¬ 
political  organization.  It  is  an  association  of  individuals  as 
distinguished  from  an  organization  of  commercial  companies.  The 
ten  persons  nominated  by  company  members  participate  as 
individuals . 


V  y.. 


It  is  not  within  the  scope  of  any  American  Defense  Preparedness 
Association  meeting  or  activity  to  discuss  or  be  at  all  concerned 
with  matters  of  trade,  procurement,  price,  market  or  control  or 
with  placement  of  specific  contracts  or  allocation  of  materials. 

The  Association  cooperates  to  every  practical  extent  with  other 
recognized  technical  and  industrial  associations  in  assisting  the 
Armed  Services  of  the  United  States.  Its  mission  is  to  keep 
America's  armament  strong  in  peace  and  in  war.  Its  functions  are 
as  important  and  as  worthy  of  support  in  times  of  international 
quiet,  as  well  as  in  emergency.  It  is  a  peace  society  in  purpose, 
in  operations,  and  in  fact. 
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AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 


TECHNICAL  DOCUMENTATION  DIVISION' 
STATEMENT  OF  AIMS  AND  PURPOSES 


The  Technical  Documentation  Division  4a.  part  of  the  Defense  Manage¬ 
ment  Group  of  the  American  Defense  Preparedness  Association.  The 
division  was  formed  to  provide  the  government  and  industry  access 
to  a  group  of  experienced  and  responsible  administrators  and 
specialists  from  various  sectors  of  industry,  qualified  to  assist 
in  the  formulation  of  government  and  industry  requirements  for 
technical  documentation,.  The  members  participate  as  individuals 
rather  than  representatives  of  their  companies. 

The  division  is  concerned  with  all  aspects  of  technical  documenta¬ 
tion:  conception,  analysis,  preparation,  management,  control,  and 
dissemination.  The  division's  field  of  interest  includes  engineer¬ 
ing  drawings  and  standards,  policies  and  procedures,  technical 
publications,  specifications,  configuration  controls,  computer- 
aided  documentation  techniques,  and  methods  of  data  communication. 
Duplication  of  effort  by  other  technical  and  industry  associations 
is  avoided. 

Sections/Committees  are  established  to  study  problems  and  submit 
resulting  reports  and  recommendations.  Section/Committee  partici¬ 
pation  by  an  individual  is  voluntary  and  evidences  his  desire  to 
comprehend  government  and  industry  needs,  to  reduce  the  complexity 
and  cost  of  technical  documentation,  and  to  enhance  standardiza¬ 
tion  with  a  sincere  interest  to  serve  with  other  members  to  achieve 
these  goals. 

Division/Section  members  interface  frequently  with  their  counter¬ 
parts  in  government  and  industry.  This  association  serves  as  a 
clearinghouse  for  professional  information  interchange  and  provid¬ 
es  a  stimulation  which  contributes  toward  the  success  of  the 
participant's  work  and  enhances  the  individual's  value  to  his 
employer. 

In  addition  to  section/committee  reports  on  subjects  completed  or 
in  process,  the  Technical  Documentation  Division  convenes  annual¬ 
ly  and  conducts  a  program  of  timely  subjects  to  keep  the  members 
and  the  public  informed,  alert,  and  interested  in  the  problems  and 
solutions  associated  with  technical  documentation  vital  to  our 
national  defense,  industrial  accomplishments,  and  other  related 
programs. 
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Technical  Publications  Section 


R.E.  Knob 


In  every  field  of  human  activity  there  are  those  who 
lead  and  those  who  are  led.  Occasionally,  among  the 
leaders  there  are  individuals  who  achieve  superior  stature. 
In  the  field  of  Engineering  Documentation,  Robert  H. 
Stearns  was  one  who,  through  dedication  to  principle 
and  aggressive  pursuance  of  duty,  earned  outstanding 
recognition  in  both  industry  and  military  circles. 

Born  in  1906  in  New  York  City,  Mr.  Stearns’  career 
included  training  both  as  a  machinist  and  in  engineering 
at  White  Motor  Co.,  and  as  a  drawing  checker,  chief 
checker,  chief  draftsman  and  engineering  consultant 
during  twenty-five  years  of  service  with  the  Douglas  Air¬ 
craft  Company. 

He  was  also  active  personally  and  as  the  Douglas 
representative  on  various  industry  association  activities, 
special  advisory  committees  to  the  Department  of  Defense 
and  with  the  Engineering  Data  Management  Section  of 
the  American  Ordnance  Association.  He  was  taken  from 
us  by  a  most  unfortunate  aircraft  accident  en  route 
home  from  a  meeting  of  the  Steering  Committee  of  the 
Engineering  Data  Management  Section  in  February  1 962. 

In  recognition  of  his  outstanding  achievements, 
the  Robert  H.  Stearns  Award  was  established  for  the 
purpose  of  honoring  Mr.  Stearns  and  as  a  vehicle  to  recog¬ 
nize  and  honor  those  who  might  exhibit  comparable 
qualities  and  achievement  in  the  future.  Specifically, 
candidates  for  the  Award  are  judged  on  the  basis  of 
demonstration  of  outstanding  qualities  in  the  following 
attributes: 


•  Devotion  to  the  field  of  documentation  and 
meaningful  achievement  therein 

•  Vigorous  and  articulate  in  establishing  and 
logically  supporting  a  position 

•  Energetic  with  singleness  of  purpose 

•  Patriotic,  honorable,  pleasant,  humble,  sincere. 

• 
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Mr.  Richard  E.  Knob  has  been  actively  engaged  in  the  field  of  Technical  Documentation  for 
over  thirty-six  years.  He  is  a  Graduate  of  Union  College  and  has  completed  Graduate 
courses  at  Polytechnic  Institute  of  New  York  and  at  Harvard  University.  He  was  listed  in  Who’s 
Who  in  the  East,  1979/1980. 

Mr.  Knob  joined  Sperry  Gyroscope  Division  of  Sperry-Rand  Corporation,  Great  Neck, 
New  York  in  1947  as  a  Publications  Engineer  and  is  now  Manager  of  Publications. 

During  World  War  II  he  served  with  the  U.S.  Navy  for  four  years  as  a  Lt.  J.G. 

Mr.  Knob  joined  the  Engineering  Data  Mangement  Section  of  the  American  Defense 
Preparedness  Association  in  1960  and  has  been  Chairman  of  the  Technical  Publications  Section  since  1968.  During  this 
period  he  provided  such  leadership  functions  as:  Co-chairman  "Equipment  Manuals  Symposium”  in  Detroit,  Michigan 
in  1965,  the  first  in  a  series  of  army  briefings  on  latest  automation  approaches  for  preparation  of  technical  manuals; 
program  Chairman  Technical  Publications  section  meeting  on  "Computer  Aided  Education”  held  at  the  U.S.  Naval 
Academy  in  1969;  Chairman  for  six  (1978-1983)  Technical  Publications  workshops  held  during  annual  meetings  of  the 
Technical  Documenation  Division. 

He  is  a  major  contributor  to  the  development  of  ADPA  responses  to  numerous  drafts  of  Government  Technical 
Manual  Specifications  &  Standards. 

Considering  his  ADPA  activities  for  over  20  years  he  can  be  cited  for  his  dedication  to  improving  Technical 
Communications  (Technical  Manuals,  Proposals,  Reports,  Provisioning  Documentation)  within  and  between  industry 
and  Department  of  Defense  components.  His  contributions  have  provided  information  and  different  view  points  to 
improve  understanding.  His  key  concern  in  recent  years  has  been  the  impact  of  changing  conditions  brought  about  by 
automation  and  other  technological  advances.  He  has  observed,  first  hand,  the  operation  areas  and  has  encouraged 
feedback  from  the  Technical  Communication  Users. 

He  and  his  wife  Helen,  live  in  Wantagh,  New  York.  They  have  six  children  and  twelve  grandchildren. 

Mr.  Knob  enjoys  boating,  tennis  and  swimming. 

A  person  who  possesses  the  unique  qualities  and  high  standards  to  merit  this  award  -  devotion  to  the  field  of 
documentation,  articulate,  energetic,  patriotic,  pleasant,  sincere,  honorable  -  is  Richard  Knob. 
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Good  Morning,  Ladies  and  Gentlemen.  I  would  like  to  welcome  you 
to  the  26th  Annual  Meeting  of  the  Technical  Documentation  Division 
and  take  this  opportunity  to  thank  the  Executive  Board  and  in  par¬ 
ticular  our  Program  Manager,  Bob  Carrier  of  the  Raytheon  Company 
and  Captain  Nelson  Jackson  of  ADPA  Headquarters  for  their  efforts. 

The  Technical  Documentation  Division  is  part  of  the  Technology  and 
Management  Advisory  Services  of  ADPA.  The  Divison  was  formed  to 
provide  the  Government  and  Industry  access  to  a  group  of  experi¬ 
enced  and  responsible  specialists  from  various  sections  of  industry 
qualified  to  assist  in  the  formulation  of  government  and  industry 
requirements  for  technical  documentation.  Members  participate  as 
individuals  rather  than  representatives  of  their  companies. 

Our  Sec t ions / Commi t tees  are  established  to  study  problems  and  sub¬ 
mit  resulting  reports  and  recommendations.  Their  objective  is  to 
comprehend  Government / Indus  try  needs,  to  reduce  complexity  and 
cost  of  technical  documentation,  and  to  enhance  standardization 
with  other  members  to  achieve  these  goals. 

Our  S e c t ions / Commi t t e es  interface  frequently  with  their  counter¬ 
parts  in  Government.  This  association  serves  as  professional 
information  interchange  and  contributes  to  solutions  associated 
with  technical  documentation  vital  to  our  national  defense  and 
industrial  accomplishments. 


I  would  like  to  take  this  opportunity  to  introduce  the  Executive 
Board . 

Since  our  meeting  at  Fort  Monroe,  Virginia  last  year,  the  Execu¬ 
tive  Board  has  met  in  Kent,  Washington  at  the  Boeing  Aerospace 
Company  and  in  Alexandria,  Virginia  at  the  Defense  Logistics 
Agency,  Cameron  Station. 

In  line  with  our  efforts  to  maximize  technology  transfer,  we 
•attempt  to  meet  with  individuals  who  can  contribute  to  our 
objectives.  At  Boeing,  the  President  Elect  of  the  ADPA  Northwest 
Chapter  provided  us  a  briefing  and  overview  of  Boeing's  activity, 
as  related  to  ballistic  missile  weaponry.  One  of  the  highlights 
of  our  meeting  was  th'e  tour  of  the  Assembly  Facilities  where  the 
747  and  new  767s  are  produced. 

At  DLA,  Cameron  Station,  we  were  extremely  fortunate  to  have 
Mr.  John  Mlttino,  Assistant  Deputy  Under  Secretary  of  Defense 
for  Production  Support  address  the  Executive  Board  and  Guests. 

He  stated  that  ADPA  is  recognized  as  a  staunch  supporter  of  our 
Nation's  defense  efforts.  Mr.  Mittino  also  stated  that  DOD/ 
Industry  changes  are  inescapable  in  the  area  of: 

o  New  methods  in  the  acquisition  of  data, 
o  New  methods  in  data  management. 

o  Reduction  of  data  (13,000  data  lists  when  services- 
owned ;  now,  more  things  will  be  happening  with  less 
data) . 

o  Determining  data  requirements  before  new  contracts 
is  going  to  be  difficult  in  evolving  "Star  Wars" 
environment . 

o  Data  "accountability"  is  increasing. 

o  Stress  the  use  of  the  same  data  and  formats  used  by 
indus  try . 

Disadvantages  of  changing  data  requirements: 

o  Planning  and  education  (especially  in  DOD)  is  critical 
in  the  areas  of : 

1.  Increased  needs  for  data  base  system  and  security. 

2.  Impact  of  p r ime- to- s ub con t r a c t or  data  problems 
where  the  subcontractor  will  not  normally  have 
any  data  base  system(s). 

3.  Pricing  of  data  will  be  more  difficult  -  how  do  you 
price  this  evolving  "electronic"  data? 


On  the  non- technical  side  - 

o  Large  impact  of  automated  data  base  trend  on  the  way 
we  do  business  today  in  the  areas  of: 

1.  Handling/transf er  of  engineering  drawings. 

2.  Engineering  data  base  repositories. 

3.  Technical  manuals. 

o  What  would  characteristics  of  1990  manuals  be? 

o  Probably  always  will  be  a  requirement  for  paper; 
however,  data  can  be  tailored  to  specific  needs 
by  the  automated  data  base  systems  (e.g.,  automatic 
listing  of  tools  and  parts  by  computer). 

At  this  same  meeting,  the  Defense  Material  Specifications 
and  Standards  Office  (DMSSO)  provided  a  report  which  included: 

Technical  Manuals  -  Mr.  John  T.  Winters  addressed  the  present 
inability  to  update  technical  manuals  in  a  timely  manner  and 
the  potential  of  the  Automated  Publication  System  (APS)  in 
resolving  that  problem. 

Mr.  Carl  Berry  discussed  Data  Item  Descriptions  and  Paper 
Reduction. 

Mr.  James  Dalgety  provided  an  insight  into  the  Efforts  to 
Automate  Technical  Data  Repositories. 

Mr.  James  D.  Richardson  provided  the  following  conclusion  to 
the  DMSSO  report: 


o  Operational  system  by  this  time  next  year  (1985). 

o  Only  4%  of  data  items  are  affected  by  "proprietary  rights". 

o  8%  of  technical  data  that  is  acquired  is  never  received. 

o  Level  3  drawing  packages  often  do  not  include  required 

reference  data. 

o  Manufacturing  data  would  increase  technical  data  total  by 
60%  . 

o  Manufacturing  data  is  normally  tailored  to  one  manufacturer 
and  useless  to  DOD. 
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o  The  Brooks  Committee  is  studying  acquisition  of  all  data. 
Expect  this  report  back  by  March. 

Mr.  Philip  W.  Clark  made  a  presentation  regarding  DLA  techni¬ 
cal  data  management  and  acquisition: 

o  Emphasis  on  tech  data  systems  and  spares  support, 
o  Automation  of  Data  Repositories. 

o  Need  resolution  of  drawing  acquisition  problems. 

o  Get  industry  to  help  DLA  in  data  acquisition. 

o  DLA  looking  at  improvements  and  plan  of  action  -  would 
like  any  industry  inputs. 

I  feel  these  two  meetings  were  outstanding  from  the  standpoint  of 
information  and  interfacing  with  the  right  people. 

Another  significant  event  of  the  year  was  the  Classified  TMAS  Meet¬ 
ing  held  at  the  National  War  College.  Six  Deputy  Undersecretaries 

of  Defense  made  presentations,  including  Richard  D.  Delauer  and 
Mary  Ann  Gillece. 

Our  exchange  with  many  of  the  Government  and  Industry  activities 
is  very  rewarding  and  is  based  upon  mutual  concern  for  our  de¬ 
fense  posture,  improving  productivity  and  reducing  overall  costs. 

I  am,  however,  concerned  over  the  near  future.  My  concern  is  for 
"bad  press"  and  our  reaction  to  half  truths  or  exceptions  rather 
than  to  the  "norm". 

One  area  of  concern  is  that  of  data  acquisition.  It  would  appear 
that  certain  legislation  in  response  to  "spares  breakout", 
acquisition  of  competitive  reprocurement  packages,  and  proprietary 
rights  is  creating  a  great  deal  of  confusion  and  may  ultimately  re¬ 
sult  in  significantly  higher  costs  for  data. 

To  evidence  my  concern,  let  me  read  from  some  of  the  new  legisla¬ 
tion: 

98th  Congress,  1st  Session,  H.R.4092,  Technical  Data,  Sec.  6 
Section  2386  of  title  10,  United  States  Code: 

"(b)(1)  Except  as  provided  in  paragraph  (3),  funds  ap¬ 
propriated  to  a  military  department  that  are  available 
for  the  development  or  production  (whether  by  a  domestic 
or  foreign  contractor)  of  a  major  weapon  system  shall  also 
be  used  for  the  acquisition  of  all  manufacturing  data  re¬ 
lating  to  such  system. 


"(2)  Each  contract  made  by  a  military  department  after 
the  date  of  the  enactment  of  the  Small  Business  Com¬ 
petitive  Procurement  Act  of  1983  for  the  development 
or  production  of  a  major  weapon  system  shall  contain 
provisions  necessary  to  carry  out  the  purposes  of  para¬ 
graph  (1),  including  conditions  under  which  the  contrac¬ 
tor  waives  proprietary  rights  with  respect  to  any  manufac¬ 
turing  data  necessary  for  the  performance  of  a  contract 
for  the  production  of  that  weapon  system  by  another  manu¬ 
facturer"  . 

On  a  recent  proposal  in  a  DOD  FAR  Supplement  we  find 
52.246-7001  Warranty  of  Data.  As  prescribed  at  46,770, 
insert  the  following  clause: 

WARRANTY  OF  DATA  (NOV  1974)  .  .  .  the  Contractor  war¬ 

rants  that  all  technical  data  delivered  under  this 
contract  will  at  the  time  of  delivery  conform  with 
the  specifications  and  all  other  requirements  of  this 
contract.  The  warranty  period  shall  extend  for  three 
(3)  years  after  completion  of  the  delivery  of  the  line 
item  of  data  (as  identified  in  DD  Form  1423)  of  which 
the  data  forms  a  part;  or  any  longer  period  specified 
in  the  contract . " 

"(3)  In  additon  to  the  remedies  specified  under  (d)(1) 
and  (2)  above.  Contractor  shall  be  liable  to  the  Govern¬ 
ment  for  all  damages  sustained  by  the  Government  as  a 
result  of  breach  of  the  warranty  specified  in  this  clause". 

"(i)  with  respect  to  the  requirement  under  Category  E  or 
I  of  MIL-D-1000,  provided  that  the  data  furnished  by  the 
Contractor  was  current,  accurate  at  time  of  submission 
and  did  not  involve  a  significant  omission  of  data  neces¬ 
sary  to  comply  with  such  requirements;" 

It  should  be  noted  that  MIL-D-1000  and  application  of  Categories 
has  been  obsolete  for  approximately  10  years. 

In  a  recent  proposed  modification  of  Paragraph  (h)  of  DAR  7-104.9 
(a)  it  stated 

"(3)  The  contractor  shall  notify  the  contracting  officer 
whenever  a  component,  module,  assembly,  or  part  can  no 
longer  be  acquired,  is  no  longer  being  manufactured,  or 
is  declared  obsolete  by  its  manufacturer.  The  notifica¬ 
tion  shall  be  made  no  later  than  thirty  days  after  the 
contractor  is  notified  by  a  subcontractor,  or  becomes 
aware  through  another  source,  of  the  discontinuance  or 
obsolescense  of  the  item." 


"(5)  For  the  purposes  of  this  clause,  the  Contracting 
Officer  shall  have  the  right  to  direct  the  contractor 
to  deliver  all  technical  data  and  computer  software, 
described  in  subparagraph  (1),  at  any  time  following 
the  60th  month  after  the  delivery  of  the  first  item 
or  at  any  time  following  two  years  after  the  acceptance 
of  all  items  (excluding  data  and  computer  software)  to 
be  delivered  under  this  contract  or  termination  of  this 
contract,  whichever  is  earlier." 

98th  Congress  1st  Session  H.R.2133  states  in  (4) (A) 

"Such  rules  and  regulations  shall  be  promulgated  as  a  part 
of  the  Federal  Acquisition  Regulations  and  shall  give  due 
consideration  to  the  following  - 

"(ii)  the  governmental  interest  to  increase  com¬ 
petition  and  lower  costs  by  developing  and  locating 
alternative  sources  of  supply  and  manufacture; 

(iii)  directing  appropriate  purchasing  agencies  to 
establish  reverse  engineering  programs  which  provide 
domestic  small  business  concerns  an  opportunity  to 
purchase  or  borrow  spare  or  replacement  parts  from  the 
Go”ernment  for  the  purpose  of  design  replication  or 
modification  to  be  used  by  such  concerns  in  the  sub¬ 
mission  of  subsequent  offers  to  sell  the  same  or  like 
parts  to  the  Government:" 

"(v)  a  requirement  that  the  procuring  agency,  with  respect 
to  each  major  system  acquisition,  insert  a  clause  in  the 
initial  production  contract  pertaining  to  technical  or 
other  data  developed  in  whole  or  in  part  with  Federal  funds. 
Such  clause  shall  contain  provisions  specifying,  as  appro¬ 
priate,  the  Government's  right  to  own,  license,  use  or 
otherwise  access  such  data  and  the  extent,  if  any,  or  pro¬ 
prietary  interest  maintained  by  the  contractor;  and 

"(vi)  the  imposition  of  appropriate  remedial  measures 
against  business  concerns  which  improperly  designate 
technical  or  other  data  as  proprietary." 

And  finally  we  have  the  Nichols'  Bill,  an  Amendment  In  The 
Nature  of  A  Substitute  to  H.R.5064,  adopted  by  the  Committee 
on  Armed  Services,  April  3,  1984.  This  Bill  requires  extensive 
study  but  my  first  reaction  to  the  draft  is  one  of  great  concern. 

We  will  have  an  opportunity  to  discuss  the  subject  later  at  the 
Configuration  Management  Workshop. 


If  such  as  I  have  read  doesn’t  drive  data  costs  out  of  sight, 
compound  the  problem  with  current  attempts  at  automation, 

CAD/CAM,  and  data  base  management,  try  to  combine  unrealistic  re¬ 
quirements  with  new  and  undeveloped  methods  of  information 
transferred  and  then  try  to  predict  the  results.  The  acquisi¬ 
tion  of  magnetic  tapes,  discs,  electronic  transfer  of  digitized 
data  without  intelligent  control  can  smother  the  government 
with  costly  useless  information. 

It  is  apparent  that  various  disciplines  in  this  country 
interpret  data  requirements  in  many  forms.  I  feel  that 
it  is  extremely  necessary  for  g ov e r nmen t / indus t r y  to  pull 
together  these  disciplines  which  normally  do  not  talk  to 
each  other  and  make  sure  that  their  requirements  for  data 
are  not  redundant,  not  inappropriate  or  overly  costly  to 
government  and  the  taxpayers.  This  country  has  been  built 
on  a  competitive  system  and  that  competitive  system  must  be 
protected. 

DOD  Instruction  5010.12  does  not  suggest  that  Contractors  be 
managed  or  monitored  through  deliverable  data.  Data  should 
stand  alone  to  support  the  mission. 

At  last  year's  meeting,  in  my  annual  report,  I  stated  that 
American  productivity  was  down  due  to  the  lack  of  intelligent 
application  of  resources.  I  stated  that  the  majority  of  us 
spend  most  of  our  time  investigating  problems  and  negotiating 
a  course  of  action  rather  than  resolving  the  problem.  Most  of 
these  problems  ste.  from  interpretations  of  contract  specifi¬ 
cation  and  standards  requirements.  The  problem  is  complicated 
by  the  remoteness  of  our  customers  and  the  inability  to  obtain 
decisions  in  a  timely  manner,  coupled  with  the  conflict  of 
Government  requirements  versus  the  way  a  company  does  or  wants 
to  do  business.  As  a  result,  there  are  roadblocks,  frustra¬ 
tion,  misinterpretations,  misapplications  and,  in  general,  an 
overall  reduction  in  productivity. 

It  was  at  this  point  that  I  asked  what  we  could  do  about  it? 

In  particular,  what  could  ADPA  and  the  Technical  Documentation 
Division  do  about  it? 

ADPA  and,  in  particular,  the  Technical  Documentation  Division, 
as  a  strong  government/ indus try  team  can  and  must  put  its 
shoulder  to  the  wheel  and  resolve  these  problems  whether  they 
be  real  or  fictional.  We  must  educate  all  factors  of  the 
mil i t ary / indus try  complex.  The  areas  of  concern  include  the 
acquisition  process,  appropriate  tailoring  to  reduce  costs, 
adequate  coverage  for  life  cycle  support,  spares  breakout, 


and  adequate  design  disclosure  protection  of  proprietary 
rights. 


I  hope  from  this  26th  Annual  Meeting  we  can  come  up  with 
recommendations  which  will  improve  the  current  working 
environment . 


Thank  you . 
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GOVERNMENT  PANEL 


ON 

TECHNICAL  DOCUMENTATION 


Chairman: 

Mr.  James  D.  Richardson,  Staff  Director 
Technical  Data  Division 
Defense  Material  Specifications 
and  Standards  Office 


Panel : 

Capt.  David  L.  Boslaugh,  USN 

Director  Embedded  Computer  Systems 
Naval  Material  Command 

Mr.  Robert  R.  Hegland 

Senior  Computer  Specialist 
US  Army  Computer  Systems  Command 

Dr.  Larry  M.  Lindley,  Program  Mgr. 

Embedded  Computers  and  Tactical  Software 
Navy  Avionics  Center 

Mr.  D.  Berton  New! in,  DMSSO 
General  Engineer  and  Sr.  Staff  Specialist 


See  Sections  B,  C,  D,  and  E  for  Government  panel  reports. 


STANDARDIZATION  AND  OVERVIEW  OF  DOD 
SOFTWARE  DOCUMENTATION  ACTIVITIES 


I 


BY 

D.  BURTON  NEWLIN,  JR 


DEFENSE  MATERIEL  SPECIFICATIONS  AND  STANDARDS  OFFICE 
OFFICE  OF  THE  UNDER  SECRETARY  OF  DEFENSE 
(RESEARCH  AND  ENGINEERING) 

ABSTRACT:  The  Department  of  Defense  has  become 
increasingly  dependent  on  computer  technology  to  accomplish 
its  mission  since  our  defense  strategy  is  based  on  high 
technology.  Computer  costs  are  consuming  a  larger 
percentage  of  the  DoD's  budget  and  this  percentage  is 
increasing.  The  major  cost  involves  the  acquisition 
and  maintenance  of  the  computer  software,  which  is 
labor  intensive,  while  the  computer  hardware  costs 
are  continuing  to  decline.  Our  future  success  on  the 
battlefield  will  depend  on  the  maturity  of  our  computer 
technology  and  its  applications.  Four  major  programs 
form  the  basis  for  our  computer  technology  program. 

These  are  our  VHSIC,  Ada,  STARS  and  Strategic  Computing 
Programs.  The  VHSIC  Program  is  addressing  the  hardware 
issues.  The  Ada  and  STARS  programs  are  addressing  the 
software  issues.  Recently  a  policy  decision  was  made 
within  the  Department  of  Defense  to  mandate  the  use 
of  Ada  for  mission-critical  applications.  The  Strategic 
Computing  Program  is  addressing  the  areas  of  application 
and  use  of  artificial  intelligence  and  expert  systems 
technology. 

Public  Law  96-511  is  an  important  law  that  was  passed 
to  encourage  the  transition  from  our  current  paper  informa¬ 
tion  society  to  an  electronic  information  society.  One  of 
its  purposes  is  to  ensure  that  automatic  data  processing 
and  telecommunications  technologies  are  acquired  and  used 
by  the  Federal  Government. 

The  development  and  documentation  of  software  has  become 
a  critical  component  in  the  weapon  system  development,  deploy¬ 
ment,  maintenance  and  logistics  processes.  Two  of  the  major 
documentation  standards  activities  within  DoD  involve  the 
Automated  Data  Systems  Documentation  Standard,  DoD-STD-7935 , 
used  by  the  ADP  community  and  a  new  standard  being  developed 
by  the  Joint  Logistics  Commanders,  MIL-STD-SDS,  Defense 
System  Software  Development  Standard. 

KEY  WORDS:  Ada,  Computer,  P.L.  96-511,  Software  Documentation, 
Standardization,  STARS,  Strategic  Computing,  VHSIC. 
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Computer  Technology  is  a  Critical  Defense  Resource 

Dr.  Martin,  the  Deputy  Under  Secretary  for  Research  &  Advanced  Technology, 
made  the  following  statement  before  the  Defense  Appropriations  Subcommittee. 

"The  United  States'  potential  adversaries  are  numerically  superior, 
technologically  sophisticated,  well  equipped,  and  prepared.  Years  ago  the 
United  States  made  the  decision  not  to  match  its  potential  adversaries,  mainly 
the  Soviet  Union  and  the  Warsaw  Pact,  on  a  person  for  person,  tank  for  tank 
basis.  Instead  we  decided  to  base  our  defense  strategy  on  superior  technology. 
A  main  ingredient  in  our  technology  strategy  is  the  use  of  "smart"  weapons; 
i.e.,  weapons  and  weapons  systems  which  have  computers  and  software  as  inte¬ 
gral  components.  In  fact,  computers  and  software  have  become  essential  to 
the  military  mission.  Almost  every  defense  system  fielded  today  contains  a 
computer  and  has  sensors,  electronic  warfare  systems,  intelligence  analysis, 
weapon  system  control,  communications,  command  and  control,  navigation, 
surveillance,  target  acquisition,  and  combat  support  services.  We  believe 
that  the  future  success  on  the  battlefield  will  depend  on  the  maturity  of  our 
computer  technology  and  its  applications"  [1]. 

The  Department  of  Defense  has  become  increasingly  dependent  on  computer 
technology  to  accomplish  its  mission.  Computer  costs  are  consuming  a  larger 
percentage  of  the  DoD's  budget  and  its  percentage  is  increasing.  The  major 
cost  involves  the  acquisition,  maintenance  and  improvement  of  the  computer 
software  or  computer  programs,  which  are  labor  intensive,  while  the  computer 
hardware  costs  are  continuing  to  decline  [2].  Four  major  defense  programs 
form  the  basis  for  our  computer  technology  program.  These  are  our  VHSIC, 

Ada,  STARS  and  Strategic  Computing  Programs. 

VHSIC  Program 

One  of  the  highest  priority  technology  programs  in  the  U.S.  Department  of 
Defense  is  the  Very  High  Speed  Integrated  Circuits  (VHSIC).  The  program  is 
aimed  at  developing  silicon  chips  that  will  be  fast  and  reliable  enough  to 
ensure  continuing  U.S.  superiority  in  defense  electronics.  The  VHSIC  Program 
will  emphasize  innovations  in  design  architecture,  software  and  testing  that 
are  key  elements  to  achieving  the  programs  goal  of  building  military  systems 
which  execute  tens  of  millions  of  instructions  per  second.  Reducing  size  and 
increasing  the  number  of  functional  components  on  a  chip  will  lead  to  signifi¬ 
cant  increases  in  speed  simply  by  reducing  the  time  needed  to  move  a  bit  of 
information  from  one  part  of  the  system  to  another.  The  program  is  being 
executed  by  six  of  the  nation's  contractors,  Honeywell,  Inc.,  Hughes  Aircraft 
Co.,  IBM  Corp.,  Texas  Instruments  Inc.,  TRW  Inc.,  and  Westinghouse  Corp. 

Ada-'-'  Programming  Language 

A  major  emphasis  on  the  standardization  of  high  order  languages  for 
weapon  system  computer  application  is  being  placed  on  the  Ada  programming 
language  specified  in  ANSI/MIL-STD- 1815A- 1983  [3].  Ada  was  developed  to 
provide  the  foundation  for  standardization  of  software  used  in  real  time 
computer  applications  and  to  reduce  both  the  initial  acquisition  and  life 
cycle  maintenance  costs  of  major  systems.  Ada,  which  has  been  adopted  as  an 


'-Ada  is  a  trademark  of  the  U.S.  Department  of  Defense. 


American  National  Standards  Institute  (ANSI)  standard.  As  an  ANSI  standard, 
this  will  hopefully  expand  the  use  of  Ada  to  other  communities  outside  the 
Department  of  Defense  and  improve  the  overall  software  development  and  soft¬ 
ware  transportability  difficulties  we  face  today. 

On  June  10,  1983,  Dr.  Richard  DeLauer,  Under  Secretary  of  Defense 
released  a  memorandum  regarding  Interim  DoD  policy  on  Computer  Programming 
Languages . [4]  This  memorandum  states  that  "the  Ada  programming  language 
shall  become  the  single,  common  computer  programming  language  for  Defense 
mission-critical  applications.  Effective  1  January  1984  for  programs  enter¬ 
ing  Advanced  Development  and  1  July  1984  for  programs  entering  Full-Scale 
Engineering  Development,  Ada  shall  be  the  programming  language.  "Mission- 
critical"  applications  are  those  exempted  from  the  Brooks  Act  by  10  U.S.C. 
2315,  as  stated  in  the  Warner  Amendment  to  the  FY  1982  Defense  Authorization 
Act."  Mission  critical  systems  include  the  following:  (a)  Intelligence 
systems,  (b)  Cryptologic  Systems  related  to  National  Security,  (c)  Command 
and  control  of  military  forces,  (d)  Integral  part  of  a  weapons  system,  or 
(e)  Critical  to  the  Direct  Fulfillment  of  Military  or  Intelligence  Missions. 

STARS  Program 

The  Department  of  Defense  has  introduced  a  software  initiative  called  the 
Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  Program. [5]  This 
program  is  directed  at  controlling  the  cost  growth  and  improving  the  quality 
and  productivity  of  DoD  computer  software  embedded  within  our  weapon  systems, 
which  has  been  predicted  to  reach  $32  billion  within  DoD  by  1990.  The  goal  of 
STARS  is  to  improve  the  software  environment  while  achieving  greater  systems 
reliability  and  adaptability.  The  program  is  aimed  at  achieving  major 
improvements  in  the  development  and  life  cycle  support  process,  to  make  this 
process  faster,  less  expensive,  and  more  predictable.  Software  documentation 
is  an  issue  the  STARS  Program  will  address. 

STARS  will  create  an  "Automated  Software  Factory",  a  coherent  and  inte¬ 
grated  system  of  computerized  software  tools  and  reusable  software  parts  and 
building  blocks.  Through  the  Automated  Software  Factory  concept,  orders-of- 
magnitude  increases  in  software  productivity  will  be  achieved,  as  will  compar¬ 
able  reductions  in  the  number  of  software  defects  latent  in  fielded  weapon 
systems.  The  Automated  Software  Factory  concept  will  address  all  of  the 
dimensions  of  software  activities  including  software  engineering,  software 
documentation,  project  management,  and  software  acquisition.  It  also  will 
build  reusable  libraries  of  software  modules  applicable  across  the  wide  range 
of  functional  areas  addressed  by  mission-critical  defense  systems,  e.g., 
navigation,  intelligence,  and  communications.  Versions  of  the  Automated 
Software  factory  will  be  used  throughout  the  Services,  Defense  Agencies, 
and  industry. [ 6 j 


Strategic  Computing  Program 

The  Defense  Advanced  Research  Project  Agency  (DARPA)  has  initiated  an 
important  new  program  in  Strategic  Computing  to  meet  the  challenge  of  certain 
critical  problems  in  defense.  By  seizing  an  opportunity  to  leverage  recent 
advances  in  artificial  intelligence,  computer  science,  and  microelectronics, 
the  Agency  plans  to  create  a  new  generation  of  "machine  intelligence  technology." 
This  new  technology  will  have  unprecedented  capabilities  and  promises  to  greatly 


increase  our  national  security  and  our  economic  strength  as  it  emerges  during 
the  coming  decade.  We  are  now  challenged  to  produce  adaptive,  intelligent 
systems  having  capabilities  far  greater  than  current  computers,  for  use  in 
diverse  applications  including  autonomous  systems,  personalized  associates, 
and  battle  management  systems.  Advances  in  "expert  system"  technology  now 
enable  the  mechanization  of  the  practical  knowledge  and  the  reasoning  methods 
of  human  experts  in  many  fields.  Advances  in  machine  vision,  speech,  and 
machine  understanding  of  natural  language  provide  new  ways  for  humans  to 
interact  with  computers.  New  ways  to  structure  the  architectures  of  computers 
enable  computations  to  be  processed  in  parallel,  leading  to  large  improvements 
in  machine  performance.  Finally,  new  methods  of  microsystem  design  and  imple¬ 
mentation  enable  the  rapid  transfer  of  new  architectural  concepts  into  state- 
of-the-art  microelectronics.  The  overall  goal  of  the  Strategic  Computing 
Program  is  to  provide  the  United  States  with  a  broad  line  of  machine  intel¬ 
ligence  technology  and  to  demonstrate  applications  of  the  technology  to 
critical  problems  in  defense. [7] 


Public  Law  96-511,  The  Paperwork  Reduction  Act  of  1980 


An  important  law  that  has  a  major  impact  on  software  documentation  is  the 
Paperwork  Reduction  Act  of  1980,  Public  Law  No.  96-511, [8],  which  establishes 
policies  and  procedures  for  controlling  paperwork  burden  imposed  by  federal 
agencies  on  the  public.  This  law  was  passed  to  encourage  the  transition  from 
our  current  paper  society  to  an  electronic  information  society  by  ensuring 
that  automatic  data  processing  and  telecommunications  technologies  are 
acquired  and  used  throughout  the  Federal  Government.  The  purpose  of  the  law 
is : 


"(1)  to  minimize  the  Federal  paperwork  burden  for  individuals, 
small  businesses,  State  and  local  governments,  and  other  persons; 

(2)  to  minimize  the  cost  to  the  Federal  Government  of  collecting, 
maintaining,  using  and  disseminating  information; 

(3)  to  maximize  the  usefulness  of  information  collected  by 
the  Federal  Government; 

(4)  to  ensure  that  automatic  data  processing  and  telecommuni¬ 
cations  technologies  are  acquired  and  used  by  the  Federal 
Government ..." 


In  April  1983,  after  four  years  of  debate  on  the  application  of  the 
law  to  DoD's  Contract  Data  requirements,  which  had  previously  been  exempted, 

0MB  and  OSD  Counsel  rules  that  all  DoD  contract  data  requirements  must  be 
approved  and  controlled  by  0MB.  Three  clearances  were  obtained  by  DoD  from 
0MB.  The  first  was  a  blanket  clearance  of  all  solicitation  documents,  such 
as  RFP's,  RFQ's.  etc.,  under  one  approval  and  expiration  date.  The  second  was 
a  blanket  clearance  of  all  FAR/DoD  Supplement  requirements  and  DD  forms  imposed 
by  FAR  under  one  approval  and  expiration  date.  The  third  was  a  blanket  clearance 
of  all  current  data  requirements  and  collection  requests  listed  in  the  Acquisi¬ 
tion  Management  Systems  and  Data  Requirements  Control  List  (AMSDL) .  Based  on 
the  clearance  for  the  AMSDL  it  is  the  only  authorized  list  of  "data  item 
descriptions"  approved  for  contractual  usage. 


The  Role  of  Standards  in  Our  Accelerating  High  Technolo; 


Standards  are  an  essential  element  to  our  high  technology  society,  yet 
most  people  understand  very  little  about  standards,  what  they  do,  who  develops 
them,  or  who  uses  them;  they  accept  standards  and  take  them  for  granted.  For 
instance,  one  of  our  most  widely  used  standards  in  the  United  States  is  the 
English  language.  Because  of  our  world  leadership  position  in  the 
industrial  era  and  in  science  and  technology,  English  has  been  universally 
accepted  as  the  language  for  communicating  technical  ideas  in  technical 
journals  and  publications.  But,  although  English  is  the  predominant  language 
in  the  U.S. ,  only  15%  of  the  world's  population  speaks  or  understands  English. 

Within  the  Federal  Government  many  of  the  computer  standards  which  are 
used  throughout  the  ADP  community,  such  as  the  Federal  Information  Processing 
Standards  (FIPS),  are  mandatory.  FIPS  are  developed  by  the  National  Bureau 
of  Standards.  But,  within  DoD,  our  military  standards  are  either  established 
by  concensus  or  decision.  Very  few  of  DoD's  standards  are  mandatory  because 
of  law  or  policy.  Since  computer  languages  had  been  allowed  to  proliferate, 
the  DoD  was  found  to  be  in  a  position  where  it  is  now  supporting  over  450 
separate  and  Service  unique  variations  of  computer  programming  languages. 

This  has  become  a  costly  and  unmanageable  situation.  Mandating  Ada  for  mission 
critical  applications  is  intended  to  increase  productivity,  encourage  competi¬ 
tion  and  ensure  that  computer  programs  can  be  maintained  and  supported  in  the 
future.  This  would  allow  more  of  DoD's  limited  computer  resources  to  be  freed 
to  concentrate  on  specific  applications. 

The  standards  development  process  often  takes  5-10  years  to  obtain  consensus, 
before  it  becomes  widely  used  and  accepted.  In  today's  high  technology  era 
the  time  needed  to  develop  related  or  associated  standards  must  keep  pace 
with  the  associated  technology.  Today,  technologies  such  as  computers, 
telecommunications,  robotics,  fiber  optics  and  lasers,  require  basic  standards 
upon  which  these  technologies  can  be  based.  These  basic  standards  become  the 
building  blocks  which  form  the  foundations  for  those  technologies. 

The  half  life  of  our  electronics  and  computer  related  technologies  is 
decreasing  at  an  accelerating  rate,  as  shown  by  the  transition  from  vacuum 
tubes  to  very  large  scale  integrated  circuits.  As  the  result,  increased  res¬ 
ponsibility  is  being  placed  on  the  standardization  community  to  work  closer 
together  with  the  scientific,  engineering  and  technology  communities,  in  order 
to  develop  future  standards  that  are  both  technology  and  vendor  independent. 

The  laws  of  "economy  of  scale"  will  determine  those  technologies  that  should 
become  standards.  The  impact  of  computer  technology  has  revolutionized  several 
of  the  standardization  areas  within  DoD  that  are  documentation  intensive.  These 
areas  include  Technical  Manuals,  Engineering  Drawings  and  the  Computer  Areas. 

The  computer  software  development  process  is  basically  a  documentation  process 
and,  in  turn,  impacts  several  other  standardization  areas.  Computer  software 
has  become  an  integral  component  in  areas  such  as  Telecommunications,  Electronic 
Information  Processing,  Computer  Aided  Design,  Computer  Aided  Engineering, 
Computer  Aided  Manufacturing  and  new  areas  such  as  Computer  Aided  Logistics 
Support  [10]. 


Software  Documentation  Activities 


There  are  numerous  contractual  documents  that  address  software  and  firm¬ 
ware  documentation  within  the  DoD.  These  include  documents  such  as  Software 
Quality  Assurance  Program  Requirements  (MIL-S-52779A) ,  Configuration  Manage¬ 
ment  Practices  for  Computer  Programs  (MIL-STD-483) .  There  are  also  Data  Item 
Descriptions  (DIDs)  that  define  the  data  (i.e.,  plans,  reports,  specifica¬ 
tions,  etc.)  to  be  prepared  and  delivered  by  contractors  to  the  Government. 

In  most  instances,  standards  will  identify  deliverable  items  of  data  in  con¬ 
nection  with  the  tasks  cited  in  other  sections  of  the  standard.  In  the 
computer  area,  there  are  over  230  DIDs  that  address  computer  documentation 
requirements;  many  of  these  result  in  duplicate,  conflicting  and  obsolete 
requirements  being  imposed  on  defense  contractors.  These  DIDs  are  being 
reviewed  to  combine,  eliminate  or  cancel  those  DIDs  which  do  not  support 
existing  standardization  or  source  document  requirements.  The  distribution 
of  computer  software  standards  and  related  data  item  descriptions  that  have 
been  identified  in  the  Embedded  Computer  Resources  Standards  (ECRS)  Area 
Standardization  Program  Plan  as  follows: 


Distribution  of  Computer  Standards 

Activities* 

Software  Area 

Standards 

DID 

0 

High  Order  Languages 

5 

- 

o 

Instruction  Set  Architectures 

4 

- 

0 

Software  Design 

10 

- 

0 

Software  Documentation 

6 

138 

0 

Software  Quality 

11 

23 

0 

Software  Reliability 

7 

- 

0 

Software  Configuration  Management 

7 

46 

o 

Software  Acquisition  Management 

5 

17 

o 

Terms/Def initions/Misc . 

_7 

— - 

Total 

62 

224 

"Embedded  Computer  Resources  Standards  Area 

Within  DoD,  several  software  documentation  standards  have  evolved  over  the 
years.  These  standards  have  been  developed  by  separate  communities  within  the 
services.  They  include  the  following: 

o  DOD-STD-7935 ,  DoD  Automated  Data  Systems  Documentation  Standards 
o  DOD-STD-1679A,  Software  Development 

o  MIL-STD-1644,  Trainer  System  Software  Engineering  Requirements 
o  MIL-STD-490,  (Type  B5),  Computer  Program  Development  Specification 
o  MIL-STD-483,  Configuration  Management  Practices  for  Systems, 

Equipment,  Munitions  and  Computer  Programs  (Appendix  VI  Computer 
Program  Configuration  Item  Specification) 
o  Air  Force  Regulation  800-14,  Acquisition  and  Support  Procedures 
for  Computer  Resources  in  Systems 

o  MIL-STD-SDS,  (Proposed)  Defense  System  Software  Development  Standard 
o  IEEE-STD-829-1983,  Standard  for  Software  Test  Documentation 
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Efforts  are  currently  underway  to  consolidate  and  combine  many  of  these 
service  unique  documentation  requirements  into  a  fully  coordinated  DoD  Standard 
for  mission-critical  application  in  the  proposed  MIL-STD-SDS.  [11]  The 
new  standard  would  then  supersede  and  cancel  the  Navy's  DOD-STD-1679A  and  MIL- 
STD-1644,  as  well  as  modify  the  requirements  in  MIL-STD-490,  MIL-STD-483  and 
MIL-STD- 1521  to  reference  MIL-STD-SDS. 

SOFTWARE  DOCUMENTATION  ASSESSMENT 

Software  documentation  has  become  a  critical  component  in  the  weapon 
system  development,  deployment,  maintenance  and  logistics  processes.  It  is 
important  that  management  supports  our  standardization  initiatives  to  reduce 
and  consolidate  the  numerous  software  documentation  standards  and  DID's.  In 
order  to  establish  standards  that  are  widely  accepted  in  this  dynamic  area  of 
technology,  it  will  require  close  working  relationships  both  within  the 
Government  and  with  industry. 
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INTRODUCTION 

The  accelerated  changes  in  technology  are  forcing  all  of  us  to  reexamine 
the  management,  control,  and  documentation  of  our  computer  resources.  In 
the  world  of  management  information  systems  (MIS)  or  automated  data  systems 
(ADS)  a  wide  variety  of  changes  in  both  hardware  and  software  are  being 
examined  by  the  Information  Processing  Standards  for  Computers  (IPSC)  0061 
committee  for  inclusion  in  DOD-STD-7935  to  enhance  the  structure  of  the 
recent  edition  which  included  provisions  for  documenting  online,  terminal- 
driven  systems. 

The  following  paragraphs  will  provide  a  brief  description  of  DOD-STD-7935  for 
those  of  you  who  may  not  be  familiar  with  it. 

OVERVIEW  OF  THE  STRUCTURE  OF  DOD-STD-7935 

There  are  three  separate  parts  to  the  standard  as  shown  in  Figure  1.  Part  1 
provides  information  about  the  scope,  applicability  and  objective  of  the 
standard.  Part  2  discusses  guidelines  for  documentation  development.  Part  3 
contains  the  detailed  outlines  and  descriptive  information  about  the  11  document 
types  in  this  system. 

HIGHLIGHTS  OF  DOCUMENTATION  DEVELOPMENT  GUIDELINES 

This  documentation  system  is  built  around  the  ADS  development  life  cycle 
shown  in  Figure  2  as  extracted  from  DODD  7920.1,  Life  Cycle  Management  of 
Automated  Information  Systems  (AIS).  Also  shown  in  Figure  2  are  the  different 
document  types  that  may  be  produced  during  the  different  phases  of  the  life 
cycle. 

There  are  many  factors  that  influence  what  documents  need  to  be  prepared 
during  the  development  effort.  These  must,  of  course,  be  determined  early 
in  the  planning  phase  to  specify  in  the  Contract  Data  Requirements  List  (CDRL) . 
Figures  3  and  4  show  a  guide  included  in  Part  2  that  can  be  used  to  help  a 
project  manager  determine  which  document  types  will  be  needed  for  the  com¬ 
plexity  of  the  system  being  developed. 


1  The  views  expressed  are  those  of  the  author  and  do  not  necessarily  represent 
those  of  any  DOD  activity. 
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Stressed  in  the  standard  and  by  the  implementors  is  the  need  for  the  manager's 
active  involvement  in  the  planning  process  for  the  documentation.  The  standard 
attempts  to  encourage  preparing  adequate,  useable  documentation  and  to  dis¬ 
courage  over-documenting.  The  manager  needs  to  consider  the  level  of  educa¬ 
tion  and  technical  expertise  of  the  readers,  the  mix  of  the  developers  between 
government  employees  and  contractors,  and  the  type  of  hardware/software  that  will 
be  used  ranging  from  batch  processing  to  desk-top,  isolated  terminals.  All 
of  these  factors  (and  more)  influence  the  quantity  and  approach  used  for  pre¬ 
paring  the  technical  documentation. 

HIGHLIGHTS  OF  THE  DOCUMENTATION  STANDARDS 

There  are  11  different  document  types  within  the  standard.  Figure  5  shows 
a  page  from  one  of  the  document  types. 

Each  of  the  document  types  is  presented  in  a  different  figure.  Each  document 
type  is  complete  in  that  the  figure  starts  with  a  Table  of  Contents  and  List 
of  Figures  and  then  shows  the  text  of  the  document.  The  paragraph  numbers 
and  titles  shown  are  the  same  as  those  that  will  be  in  the  final  document. 

The  format  used  with  decimal  paragraph  numbers,  indented  itemization,  footnotes, 
etc.  is  consistent  within  the  standard  but  is  not  a  required  part  of  the 
deliverable.  Each  implementing  service/agency  can  specify  a  different  format 
if  desired.  Most  have,  however,  simply  followed  this  format  since  it  does 
conform  with  many  typing  rules  such  as  those  for  correspondence  as  well  as 
MIL-STD-962 . 

FUTURE  PLANS 

The  standard  was  developed  using  generic  terms  such  as  input,  output,  process, 
data  base,  program,  system,  etc.  This  made  the  standard  useful  across  all 
services  and  agencies  and  for  all  hardware  and  software. 

Now  some  of  these  areas  have  become  unclear  due  to  significant  changes  in 
technology.  Some  of  these  areas  need  to  be  clarified  by  making  changes  to  the 
document  type  standards;  others  can  be  addressed  by  discussing  them  in  Part  2 
the  Development  Guidelines. 

INPUT/OUTPUT.  There  is  confusion  between  "input"  and  "output."  A  screen 
format  that  is  to  be  used  as  a  data  collection  form  for  input  from  a  terminal 
is  actually  "output"  from  the  program.  The  readers  of  the  Users  Manual  would 
not  expect  to  find  information  about  how  to  call  that  screen  under  system 
outputs.  They  would  expect  to  find  that  information  as  the  first  step  under 
how  to  enter  data." 
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SECTION  2.  SYSTEM  SUMMARY 

This  section  shall  provide  a  general  description,  written  in 
non-ADP  terminology,  of  the  existing  system  and  of  the 
requirements  for  the  proposed  ADS. 

2.1  Background.  Included  within  this  paragraph,  as  necessary, 
will  be  any  information  concerning  the  background  of  the  uses  and 
purposes  of  the  system  to  orient  the  reader.  Reference  must  be 
made  to  higher  order  and  parallel  systems  when  needed  to  enhance 
the  general  description.  The  relationships  between  the  project 
and  other  capabilities  being  developed  concurrently  shall  be 
descr ibed . 

2.2  Objectives.  Statements  of  the  major  performance 
requirements  and  goals  of  the  proposed  computer  program  system 
must  be  included.  These  statements  should  be  concise,  quantified 
if  possible,  and  may  include  examples.  When  applicable,  related 
events,  such  as  exercises  or  impending  military  operations,  may 
be  discussed.  Any  anticipated  operational  changes  that  will 
affect  the  system  and  its  use  shall  be  identified  and  the 
provisions  within  the  system  for  including  them  shall  be 
explained . 

2.3  Existing  Methods  and  Procedures.  This  paragraph  shall 
provide  a  brief  description  of  the  current  methods  and  procedures 
being  employed  to  satisfy  the  existing  information  requirements. 

A  chart  must  be  provided  depicting  the  existing  data  flow  through 
the  functional  system  from  data  acquisition  through  its 
processing  and  eventual  output.  This  chart  may  be  complemented 
oy  an  explanation  or  another  chart  showing  the  sequence  in  which 
the  operational  functions  are  performed  by  the  user  and  pointing 
out  the  support  of  those  decision  making  activities  that  is 
provided  by  the  present  system.  Additionally,  at  least  the 
following  information  should  be  included  in  this  description: 

a.  Organizational/personnel  responsibilities. 

b.  Equipment  being  utilized. 

c.  Inputs  and  outputs  including  volume  and  frequency. 

d.  Deficiencies,  including  limitations,  such  as  time 
delays. 

2.4  Proposed  Methods  and  Procedures.  A  description  of  the 
proposed  methods  and  procedures  shall  be  presented  in  this  and 
the  following  paragraphs.  This  description,  written  in  non-ADP 
terminology,  should  explain  how  the  proposed  system  will  interact 
witn  the  functional  processes  of  which  the  automated  system  will 


*> 

1 _ 


FIGURE,  3-31.  Functional  Description 


FIGURE  5.  Sample  Page  from  Functional  Description 


06 


PROGRAM  DEFINITION.  In  the  days  of  batch  processing,  we  understood  what  a 
program  in  an  application  system  was.  In  a  terminal-driven  system  today,  we  may 
have,  perhaps,  30  different  "modules"  or  "subroutines"  to  edit  screen  input.  We 
may  have  6  different  screens  and  each  of  those  may  call  some  of  the  same  modules 
and  some  unique  modules  to  edit  the  input.  Is  this  a  "program"  and  if  not,  how 
do  we  document  it?  Is  each  module  a  program?  What  is  the  screen? 

ONLINE  DOCUMENTATION.  We  have  thousands  of  desk-top  computers.  Much  of  the 
software  for  them  is  written  including  "help"  screens,  menu  selection  of 
available  options,  modules  to  be  used  to  train  a  new  user,  etc.  Does  all  this 
information  need  to  be  repeated  in  the  Users  Manual?  How  should  it  be  handled 
in  the  Program  Maintenance  Manual? 

COMPUTER  OPERATOR  FUNCTIONS.  The  terminal  user  now  performs  tasks  that 
used  to  be  the  responsibility  of  the  computer  operator  in  a  batch  processing 
environment.  That  terminal  user  now  must  resolve  errors,  make  printouts, 
make  backup  copies  of  data  bases,  etc.  Should  those  functions  be  documented 
in  a  Users  Manual  or  in  a  Computer  Operation  Manual? 

DATA  BASE.  With  the  advent  of  down-loading  of  data  from  a  large  data  base  for 
processing  on  a  terminal,  we  have  had  questions  about  how  much  information  on 
the  data  that  will  be  processed  by  this  system  or  subsystem  should  be  included 
in  the  documentation  of  that  system  or  subsystem.  Perhaps  such  information 
should  be  included  in  a  single  document  for  the  overall  data  base  and  referenced 
from  the  system  or  subsystem  documentation. 

These  are  some  of  the  areas  that  IPSC  0061  is  addressing.  There  are  pro¬ 
visions  in  the  new  (15  February  1983)  version  of  the  D0D-STD-7935  that  pro¬ 
vide  for  documenting  terminal -driven  systems  but  the  committee  is  trying  to 
enhance  these  and  to  help  new  users  of  the  standard.  Most  of  the  current 
users  have  ways  to  document  systems  with  the  characteristics  just  identified 
but  the  committee  wants  to  address  those  items  specifically  so  that  all  users 
will  be  documenting  these  systems  in  the  same  way. 

CONCLUSION 

D0D-STD-7935  is  the  standard  used  for  documenting  MIS,  ADS,  and  non-embedded 
systems.  The  committee  tries  to  meet  with  various  users  who  have  problems 
with  or  suggestions  for  the  standard.  This  standard  is  actively  maintained. 

It  has  been  improved  by  this  type  of  interaction  over  its  11  year  life  as  a 
DOD  standard.  Our  committee  looks  forward  to  active  involvement  with  users 
of  the  standard  to  gain  the  benefit  of  their  experience  and  ideas. 
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CONFLICTING.  REDUNDANT.  AND  IN  SOME  CASES. 
NONEXISTANT  SOFTWARE  DEVELOPMENT 
POLICIES  AND  STANDARDS  RESULT  IN: 
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JLC  SOFTWARE  STANDARDIZATION 
PROGRAM  OBJECTIVE 


PRODUCE  A  COMPLETE,  CONSISTENT  TRI-SERVICE  SET  OF 
ACQUISITION,  DEVELOPMENT  AND  SUPPORT  STANDARDS  WHICH: 

•  ESTABLISH  A  WELL-DEFINED  AND  EASILY  UNDERSTOOD 
SOFTWARE  ACQUISITION  AND  DEVELOPMENT  PROCESS 

•  PROVIDE  ADEQUATE  VISIBILITY  DURING  SOFTWARE 
DEVELOPMENT  AND  ACQUISITION 

•  REDUCE  CONFUSION  AND  ELIMINATE  CONFLICTS  IN  EXISTING 
STANDARDS 

•  ARE  COMPATIBLE  WITH  MODERN  METHODS  OF  DEVELOPING 
SOFTWARE 

•  PROVIDE  COST  BENEFITS  OVER  THE  ENTIRE  LIFE  CYCLE 

•  INCREASE  PROBABILITY  OF  OBTAINING  QUALITY  SOFTWARE 


SOFTWARE  DEVELOPMENT 
STANDARDIZATION  PROJECT 


•  JOINT  REGULATION,  MANAGEMENT  OF 
COMPUTER  RESOURCES  IN  DEFENSE  SYSTEMS 

•  DOD-STD-SDS 

•  TWENTY-FIVE  DATA  ITEM  DESCRIPTIONS  (DIDS) 

•  ASSOCIATED  CHANGES  TO: 

•  MIL-STD-483,  CONFIGURATION  MANAGEMENT 

•  MIL-STD-490,  SPECIFICATION  PRACTICES 

•  MIL-STD-1 521  A,  TECHNICAL  REVIEWS  AND  AUDITS 

•  TRAINING  COURSE  AND  GUIDEBOOK 


CALLED  "THE  SDS  PACKAGE" 


JOINT  LOGISTICS  COMMANDERS 
POLICY  &  STANDARDS 


POLICY 


JOINT  REGULATION 

MANAGEMENT  OF 
COMPUTER  RESOURCES 
IN  DEFENSE  SYSTEMS 


OUTLINES  EVOLUTION  OF 
COMPUTER  RESOURCES 
THROUGHOUT  SYSTEM 
ACQUISITION  LIFE  CYCLE 

DEFINES  SOFTWARE 
DEVELOPMENT  CYCLE 

ACTIVITIES  -  REVIEWS 
■  PRODUCTS  -  BASELINES 


STANDARD 


•  DEFINES  REQUIREMENTS 
FOR  A  SOFTWARE 
DEVELOPMENT 
CONTRACTOR 

•  MATCHING  DIDs  AVAILABLE 


DOD-STD-SDS  PRECEPTS 


•  A  DISCIPLINED  APPROACH  TO  SOFTWARE  DEVELOPMENT  IS 
NEEDED 

•  PROVEN  ENGINEERING  AND  ACQUISITION  MANAGEMENT 
DISCIPLINES  MUST  BE  APPLIED 

•  SOFTWARE  DEVELOPMENT  CAN  (AND  DOES)  OCCUR  AT  ANY 
POINT  IN  THE  SYSTEM  LIFE  CYCLE 

•  THE  DEVELOPMENT  AND  USE  OF  MODERN  SOFTWARE 
DEVELOPMENT  PRACTICES  SHOULD  NOT  BE  CONSTRAINED  BY 
DOD-STD-SDS 

•  MORE  ACCURATE  VISIBIl  ITY  INTO  SOFTWARE  DEVELOPMENT 
STATUS  IS  NEEDED 

•  SOFTWARE  SUPPORT  REQUIREMENTS  NEED  TO  BE  DEFINED 
EARLY  AND  ACQUIRED 
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MAJOR  DOD-STD-SDS 
CHARACTERISTICS 


•  IS  PROCESS  ORIENTED,  FLEXIBLE  AND  TAILORABLE 

•  INTEGRATES  SOFTWARE  DEVELOPMENT  PROCESS  INTO 
OVERALL  DEFENSE  SYSTEM  DEVELOPMENT  PROCESS 

•  ENCOURAGES  USE  OF  INNOVATIVE  ACQUISITION  TECHNIQUES 

•  ALLOWS  ALTERNATIVE  DESIGN  METHODOLOGIES 

•  ENCOURAGES  USE  OF  COMMERCIALLY-AVAILABLE  AND 
REUSABLE  SOFTWARE 

•  REQUIRES  USE  OF  APPROVED  SET  OF  CODING  STANDARDS 

•  REQUIRES  USE  OF  HOL  SUCH  AS  ADA 

•  EMPHASIZED  SOFTWARE  SUPPORT  REQUIREMENTS 
THROUGHOUT  DEVELOPMENT  CYCLE 

•  REQUIRES  COST  AND  SCHEDULE  TRACKING  TO  THE  CSCI  LEVEL 


IMPLEMENTATION  STRATEGY 


•  ANALYZE  EXISTING  GUIDANCE  AND  DRAFT  NEW 
STANDARDS 

•  ADOPT  AN  EVOLUTIONARY  APPROACH  BASED  ON 
EXPERIENCE  AND  TECHNOLOGY  ADVANCEMENTS 

•  INCLUDE  INDUSTRY  IN  PRELIMINARY  AND  FINAL 
REVIEWS 

•  ESTABLISH  AN  ISSUE  RESOLUTION  PROCEDURE 

•  OBTAIN  THE  SUPPORT  OF  OSD  AND  THE  USING 
COMMANDS 

•  SUPPORT  THE  IMPLEMENTATION  WITH  TRAINING 
COURSES  AND  GUIDEBOOKS 


DOD-STD-SDS  STATUS 


•  MONTEREY  I  WORKSHOP  APR  79 

•  STARTED  SDS  DEVELOPMENT  APR  81 

•  INFORMAL  GOVERNMENT  AND  INDUSTRY 

REVIEW  OF  DRAFT  JUN-OCT  82 

•  REVISED  DRAFT  APR  83 

•  JLC.EIA.AIA,  AND  NSIA  WORKSHOPS  MAY-JUL  83 

•  OVER  5000  COMMENTS 

•  42  OUTSTANDING  ISSUES 

•  FINAL  DRAFT  COMPLETED  DEC  83 

•  24  OUTSTANDING  ISSUES  RESOLVED 

•  10  OUTSTANDING  ISSUES  PARTIALLY  RESOLVED 

•  ANALYSIS  EFFORT  ON  8  OUTSTANDING  ISSUES  INITIATED 

•  FORMAL  REVIEW/COORDINATION  JAN-MAR  84 

•  AFSC  COMMENTS  SO  FAR 

-  TWO  MAJCOMS  -  “EXCELLENT  PRODUCT,  NO  PROPOSED  CHANGES" 

HQ  AFSC  LABS,  PLANS,  LEGAL,  COMPTROLLER,  TEST,  CONTRACTING, 
AND  INFORMATION  SYSTEMS  -  MINOR  CHANGES 

•  FORMAL  REVIEW  COMMENTS  INCORPORATED  APR-SEP84 

•  IMPLEMENTATION  OCT  84 

•  INITIATE  REVISION  EFFORT  OCT  84 

•  RESOLVE  8  OUTSTANDING  ISSUES 

•  INCORPORATE  FEEDBACK  FROM  FIELD  USE 


DOD-STD-SDS  STATUS 
(CONT.) 


•  PROTOTYPE  APPLICATIONS  UNDERWAY 

•  AFSC/ASD  AREA  REPROGRAMMING  CAPABILITY  PROGRAM 

•  AFSC/SO  CONSOLIDATED  SPACE  OPERATION  CENTER  PROGRAM 

•  FAA  NATIONAL  AIRSPACE  MANAGEMENT  SYSTEM 

•  BOEING  SOFTWARE  STANDARDS  MANUAL 

•  TEXAS  INSTRUMENTS  CORPORATE  POLICY 

•  EXTERNAL  AGENCIES  INTERESTED 

•  NASA 

•  DLA 

•  CIA 

•  MITRE  (TRIMIS) 

•  IN  USE 

•  JOINT  SERVICES  SOFTWARE  ENGINEERING  ENVIRONMENT 

•  SOFTWARE  TEST  AND  EVALUATION  PROJECT 

•  FAA  NATIONAL  AIRSPACE  MANAGEMENT  SYSTEM 


SOFTWARE  DOCUMENTATION 
STANDARDS 


DIDs  DEVELOPED  FOR 

•  MANAGEMENT  PLANS 

•  ENGINEERING  SPECIFICATIONS/DOCUMENTATION 

•  TEST  PLANS/PROCEDURES/REPORTS 

•  SUPPORT  DOCUMENTATION 


WILL  PROVIDE  COMMON  DOCUMENTATION  SET 


SOFTWARE  DIDs 


ENGINEERING: 

SSS  SYSTEM/SEGMENT  SPECIFICATION 
SRS  SOFTWARE  REQUIREMENTS  SPECIFICATION 

IRS  INTERFACE  REQUIREMENTS  SPECIFICATION 

STLDD  SOFTWARE  TOP  LEVEL  DESIGN  DOCUMENT 
SDDD  SOFTWARE  DETAIL  DESIGN  DOCUMENT 
IDD  INTERFACE  DESIGN  DOCUMENT 

DBDD  DATA  BASE  DESIGN  DOCUMENT 

SPS  SOFTWARE  PRODUCT  SPECIFICATION 
SPCR  SOFTWARE  PROBLEM/CHANGE  REPORT 


MANAGEMENT: 

CRLCMP  COMPUTER  RESOURCES  LIFE  CYCLE 
MANAGEMENT  PLAN 

SDP  SOFTWARE  DEVELOPMENT  PLAN 

SCMP  SOFTWARE  CONFIGURATION 
MANAGEMENT  PLAN 

SQAP  SOFTWARE  QUALITY  ASSURANCE  PLAN 

SSPM  SOFTWARE  STANDARDS  AND 
PROCEDURES  MANUAL 


VDD  VERSION  DESCRIPTION  DOCUMENT 


SOFTWARE  DIDs  (CONTINUED) 


TEST: 

STP  SOFTWARE  TEST  PLAN 

STD  SOFTWARE  TEST  DESCRIPTIONS 

STPR  SOFTWARE  TEST  PROCEDURES 

STR  SOFTWARE  TEST  REPORT 

SUPPORT: 

CSOM  COMPUTER  SYSTEM  OPERATOR'S  MANUAL 
SUM  SOFTWARE  USER'S  MANUAL 
CSDM  COMPUTER  SYSTEM  DIAGNOSTIC  MANUAL 
SPM  SOFTWARE  PROGRAMMER'S  MANUAL 
FSM  FIRMWARE  SUPPORT  MANUAL 
OCD  OPERATIONAL  CONCEPT  DOCUMENT 

SPCR  SOFTWARE  PROBLEM/CHANGE  REPORT 


MAJOR  DOD-STD-SDS  BENEFITS 


•  PROVIDES  COMMONALITY  AMONG  THE  SERVICES 

•  REDUCES  NUMBER  OF  SOFTWARE  DEVELOPMENT  METHODS 
FROM  FOUR  TO  ONE 

•  ALLOWS  OSD  AND  SERVICES  TO  CANCEL  AN  ESTIMATED  100 
DIDs 

•  REDUCES  COST  TO  CONTRACTORS  AND 
GOVERNMENT 

•  IMPROVES  CONTRACTOR  PRODUCTIVITY 

•  ALLOWS  CONTRACTORS  TO  STANDARDIZE  AND  AUTOMATE 
SOFTWARE  DEVELOPMENT  AND  MANAGEMENT  PROCESSES 

•  PROVIDES  MORE  ACCURATE  VISIBILITY  INTO 
SOFTWARE  DEVELOPMENT  STATUS 

•  CONTRIBUTES  TO  EARLY  IDENTIFICATION  OF 
SOFTWARE  ERRORS 

•  PROVIDES  A  DISCIPLINED  PROCESS  FOR  PDSS 
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Ada  Aspects 
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Compiler 

Programmer  Support  Environment 


Ada  Goals 

Common  DoD  Programming  Language 
Programming  for  Real  Time,  Embedded  Systems 
Employ  Modern  Software  Engineering  Techniques 
Suitable  for  Development  of  Large  Programs 
Facilitate  Reliability  and  Maintainability 
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Ada  Features  For  Documentation 

NAMING  RULES 

TYPE  DEFINITIONS  AND  CONVERSION 
subtypes 
derived  types 
enumeration  type 
range  specification 
error  bounds 
explicit  type  conversion 
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package  EXAMPLE  is 

with  ANOTHER-PACKAGE; 
use  ANOTHER-PACKAGE; 
type  DAY  is  (SUN,MON,TUE,WEDJHR,FRI,SAT); 
type  EXPL-INTEGER  is  range  1  .  .  100; 
type  EXPL-FLOAT-PT  is  digits  10  range  -1.0  .  .  1.0; 
type  EXPL_FIX_PT  is  delta  0.1  range  0.0  .  .  100.0; 
subtype  SUB.EXPLJNTEGER  is  EXPL-INTEGER  range  1  .  .  50; 
procedure  F1RST-PROC  (PARAM.l:  in  REAL  ;  PARAM-2  :  in  out  INTEGER); 
ERROR-1  :  exception; 
end  EXAMPLE; 

package  body  EXAMPLE  is 

procedure  FIRST- PROC  (PARAM.l  :  in  REAL  ;  P ARAM-2  :  in  out  INTEGER); 

VAR  1  :  EXPL-INTEGER; 
begin 
»  •  • 

exception 
•  *  ♦ 

end  FIRST- PROC; 
end  EXAMPLE; 
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PROBLEM:  COMPUTE 


SOLUTION:  Xt  =  initial  value 

x2  =  (*.  +  Y/X,  )  /  2 
h  =  (Xb  +  V/X2  )  /  2 

until  Xn+1  =  Xn  (approx) 


PDL 

proc  SQRT  (  fix  Y  :  real  ,  alt  X  :  real  ) 
XT  :  array 
initialize  XT(0) 

[based  on  y) 

while 

XT(I)  not  convergent 
do 

XT(I+1)  :=  (XT(I)  +  Y  /  XT(I)  )  /  2 

[compute  next  approximation] 
[increment  I] 
od 

X  :=  XT(I) 
corp 


i 


Ada  PDL 


procedure  SQRT  (  Y  :  in  REAL  ;  X  :  out  REAL  ) 
XT  :  array  (1  .  .  TBD)  of  REAL; 
begin 

initialize  XT(0) 

—  based  on  Y 

while 

XT(I)  not  convergent 
loop 

XT(I+1)  ;=  (XT(I)  +  Y  /  XT(I)  )  /  2; 

—  compute  next  approximation 
increment  I 
end  loop 
X  :=  XT(I); 
end  SQRT; 
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BACKGROUND. 


THE  EDGEWOOD  AREA  OF  ABERDEEN  PROVING  GROUND  HAS  BEEN  INVOLVED 
WITH  USING  COMPUTERS  TO  SOLVE  ENGINEERING  PROBLEMS  FOR  MANY  YEARS. 
THE  CAD  EFFORTS  BEGAN  IN  1971  WHEN  AN  AUTOMATED  DRAFTING  AND 
DIGITIZING  SYSTEM  WAS  MADE  OPERATIONAL.  THEN  IN  1974  OUR  FIRST 
INTERACTIVE  GRAPHICS  SYSTEM  WAS  INSTALLED  AND  A  SECOND  STATION 
ADDED  IN  1975,  GROWING  TO  A  TOTAL  OF  EIGHT  CAD  STATIONS  TODAY. 
CONCURRENTLY  DURING  THAT  PERIOD,  PERIPHERALS  WERE  ADDED J  HIGH 
SPEED  DRUM  PLOTTER,  COMPUTERIZED  OUTPUT  MICROFILM  (COM),  DISK 
STORAGE  INCREASED  FROM  AN  INITIAL  10  MEGABYTES  TO  600  MEGABYTES, 
3-AXIS  DIGITIZER,  MAG  TAPE  UNITS,  ETC.,  TO  OUR  PRESENT 
CONFIGURATION  TODAY. 

INTRODUCTION 

IT  IS  COMMON  KNOWLEDGE  THAT  COMPUTER  AIDED  DESIGN/DRAFTING 
(CAD)  SYSTEMS  ARE  VERY  COST-EFFECTIVE  AND  HIGHLY  PRODUCTIVE. 

THE  POWER  OF  THE  COMPUTER  HAS  RAPIDLY  BECOME  AN  INTEGRAL  PART 
OF  THE  ENGINEERING  COMMUNITY  FOR  BOTH  PRIVATE  INDUSTRY  AND 
GOVERNMENT.  THIS  ADVANCED  COMPUTER  TECHNOLOGY  IS  BEING  EMPLOYED 
TO  COMBAT  SPIRALING  COSTS,  DEVELOP  BETTER  AND  MORE  RELIABLE 
ITEMS,  THROUGH  INCREASED  DESIGN  LATITUDE,  AND  DRASTICALLY 
REDUCED  LEAD  TIME.  THE  PRESENT  AND  FUTURE  OF  CAD  TECHNOLOGY 
CAN  BEST  BE  DESCRIBED  BY  QUOTING  THE  TITLE  FROM  A  POPULAR  SONG 
SUNG  AT  MANY  WEDDINGS,  "WE'VE  ONLY  JUST  BEGUN." 
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SUCCESS  didn't  come  easy,  it  was  a  long  hard  struggle, 
for  example:  shortly  after  our  initial  cad  station  was 

INSTALLED  A  BRANCH  CHIEF  REMARKED  THAT  THE  CAD  SYSTEM  WOULD 
NEVER  BE  ABLE  TO  PRODUCE  A  LEVEL  III  PRODUCTION  ENGINEERING 
DRAWING.  ALSO,  DURING  ONE  OF  OUR  DEMONSTRATIONS,  AN  ENGINEER 
SAID  "THAT  (CAD  SYSTEM)  WILL  NOT  DO  ANYTHING  I  CAN'T  DO  ON 
THE  BOARD."  WITH  THAT  CHALLENGE  WE  SET  TO  WORK.  APPROXIMATELY 
ONE  YEAR  LATER  WE  WERE  ABLE  TO  PRODUCE  A  PRODUCTION 
ENGINEERING  DRAWING  AND  IT  WAS  BOLDLY  HUNG  ON  THE  BRANCH 
CHIEF'S  OFFICE  WALL,  AND  THE  ENGINEER  WHO  COULD  DO  THE  SAME 
ON  THE  DRAFTING  BOARD,  IS  NOW  ONE  OF  OUR  BEST  CUSTOMERS. 

I  RELATE  THIS  STORY  TO  SHOW  THE  DISBELIEF  THAT  EXISTED 
THEN  AND  STILL  EXISTS  TODAY  TO  A  LESSER  DEGREE.  WHAT  IS 
COMMONPLACE  TODAY  EITHER  DID  NOT  EXIST,  OR  WAS  VERY  DIFFICULT 
TO  PERFORM  A  DECADE  AGO.  SIMPLE  LINES  AND  CIRCLES  COULD  NOT 
BE  MODIFIED;  THEY  HAD  TO  BE  DELETED  AND  NEW  LINES  AND  CIRCLES 
CONSTRUCTED,  MOST  GEOMETRIC  MODIFIERS  WERE  UNAVAILABLE  AND 
RESPONSE  TIME  WAS  SLOW,  THIRTY-TWO  K  MEMORY  AND  30  MEGABYTE 
DISKS  WERE  CONSIDERED  LARGE. 

TODAY 

AT  PRESENT  CRDC  IS  USING  THE  CAD  UNIT  TO  ITS  FULL 
CAPABILITY  RESULTING  IN  SOME  AMAZING  COST  REDUCTIONS,  TIME 
SAVINGS  AND  QUICK  TURN-AROUND.  FOR  EXAMPLE,  NEW  DRAWINGS 
COST  30%  LESS,  AND  REVISIONS  HAVE  A  SAVINGS  OF  APPROXIMATELY 
7  TO  1.  WITH  A  YEARLY  THROUGHPUT  OF  HUNDREDS  OF  NEW  DRAWINGS 
THE  COST  SAVINGS  EMPLOYING  CAD  ARE  ENORMOUS, 


ENOUGH  ON  DOLLAR  SAVINGS,  I  AM  SURE  YOU  HEARD  IT  BEFORE 
MANY  TIMES.  INSTEAD  I  WOULD  LIKE  TO  TAKE  THIS  TIME  TO  TALK 


ABOUT  OTHER  BENEFITS  AND  PROBLEMS  WITH  CAD  SYSTEMS. 

OTHER  BENEFITS. 

1.  HANDICAPPED.  WE  HAVE  FOUND  THE  CAD  SYSTEMS  OPEN 
ANOTHER  DOOR  FOR  EMPLOYMENT  OF  THE  HANDICAPPED.  PEOPLE 
CONFINED  TO  WHEELCHAIRS  CAN  EASILY  FUNCTION  AT  A  CAD  WORK¬ 
STATION.  ALSO,  PEOPLE  WITH  THE  USE  OF  ONLY  ONE  ARM  CAN  BE 
EFFICIENT  AND  PRODUCTIVE  WITH  THE  USE  OF  A  CAD  SYSTEM. 

HANDICAPPED  HAVE  AN  EXCELLENT  REPUTATION  FOR  BEING  GOOD 
PRODUCTIVE  EMPLOYEES,  ANOTHER  SOURCE  FOR  EMPLOYERS  TO  DRAW  UPON. 

2.  QUALITY.  WE  HAVE  ALL  BEEN  EXPOSED  TO  THE  UNREADABLE 
DRAWING  -  IS  IT  A  6  OR  5,  8  OR  0,  OR  SO  ON.  WITH  CAD  ALL 
DRAWINGS  ARE  EITHER  OUTPUT  ON  A  PLOTTER  OR  COM  UNIT  WITH 
EXCELLENT  LEGIBILITY  AND  MICROFILM  QUALITY.  BLUELINE  REPRO¬ 
DUCTION  IS  ALSO  EXCELLENT,  WHEN  WET  INK  IS  USED  IN  THE  PLOTTER. 

3.  LOST  OR  DAMAGED  ORIGINALS.  DURING  MY  CAREER  I  HAVE 
SPENT  MANY  HOURS  SEARCHING  FOR  THE  LOST  ORIGINAL,  ONLY  TO  BE 
FOUND  AFTER  SPENDING  HOURS  REDRAWING  THE  LOST  DRAWING.  COFFEE 
AND  SODA  HAVE  ALSO  BEEN  RESPONSIBLE  FOR  REDRAWING  AT  GREAT  COST. 
WITH  A  CAD  SYSTEM  A  NEW  ORIGINAL  CAN  BE  GENERATED  IN  A  MATTER 

OF  MINUTES.  RETRIEVE  THE  DAMAGED  DRAWING  DATA  FROM  THE  STORAGE 
DEVICE  AND  GENERATE  A  NEW  ORIGINAL  DRAWING  ON  THE  PLOTTER, 

4.  STORAGE  SPACE.  THERE  NEVER  SEEMS  TO  BE  ENOUGH  STORAGE 
SPACE  AT  WORK,  AND  AT  HOME.  WITH  A  CAD  SYSTEM  THERE  REALLY  IS 

NO  NEED  TO  STORE  ORIGINAL  DRAWINGS,  AFTER  ALL  THEY  CAN  BE  RETRIEVED 
QUICKLY  FROM  THE  SYSTEM.  IF  YOU  ARE  FORTUNATE  ENOUGH  TO  HAVE  A 

COM  DEVICE  YOU  REALLY  DON'T  NEED  HARD  COPIES  AT  ALL. 

F-3, 


SAVES  A  LOT  OF  PAPER  AND  LABOR  NEEDED  FOR  FILING  AND  MAINTAINING 
MANUAL  DRAWING  FILES,  PLUS  YOU  ALWAYS  HAVE  YOUR  MICROFILM  FILE 
FOR  EVERYDAY  USE, 


5.  MORE  EFFICIENT  DESIGN,  THERE  IS  NO  QUESTION  IN  MY 
MIND  THAT  CAD  SYSTEM  USAGE  RESULTS  IN  BETTER  DESIGN.  SINCE 
DETAILS,  VIEWS,  ETC.,  CAN  EASILY  BE  MANIPULATED,  MOVED  AND 
SCALED,  ETC.,  WITH  NO  ERASING,  THE  DESIGNER  WILL  EXAMINE  MANY 
MORE  ALTERNATES  FOR  HIS  DESIGN.  THIS  WILL  RESULT  IN  A  MORE 
EFFICIENT  AND  fcgSS  COSTLY  OVER  DESIGN. 

6.  BOM  &  PL  GENERATION.  MOST  CAD  SYSTEMS  HAVE  FACILITIES 
TO  AUTOMATICALLY  GENERATE  A  BILL  OF  MATERIAL  (BOM)  AND  PARTS 
LIST(PL).  NOT  ONLY  IS  THIS  A  TREMENDOUS  TIME  SAVER,  BUT  RESULTS 
IN  FAR  GREATER  ACCURACY.  IT  IS  QUITE  LABORIOUS  TO  COUNT  SMALL 
ITEMS  SUCH  AS  NUTS,  BOLTS,  WASHERS,  ETC.,  ON  BOTH  LARGE  AND 
SMALL  ASSEMBLIES. 

.CAD  SYSTEM  PROBLEMS . 

NO  MATTER  HOW  GOOD  SOMETHING  IS,  IT  SEEMS  THAT  IT  ALSO  HAS 
SOME  DISADVANTAGES.  THIS  IS  ALSO  THE  CASE  WITH  CAD  SYSTEMS. 

MOST  VENDORS  AND  EVEN  SOME  USERS  TRY  TO  SWEEP  THESE  PROBLEMS 
UNDER  THE  RUG. 

LET'S  EXAMINE  SOME  OF  THE  PROBLEMS  THAT  STILL  EXIST  TODAY 
IN  VARYING  DEGREES. 

1.  ARCHIVAL  DRAWINGS.  WHAT  DO  YOU  DO  WITH  THE  THOUSANDS 
OF  EXISTING  ACTIVE  MANUAL  DRAWINGS?  HOW  DO  YOU  GET  ALL  THAT 
VALUABLE  DATA  INTO  YOUR  CAD  SYSTEMS?  WELL,  THERE  REALLY  IS  NO 
SIMPLE  QUICK,  LOW  COST  ANSWER  TO  THAT  PROBLEM  TODAY.  ALL  NEW 
DRAWING  REQUIREMENTS  ARE  SATISFIED  WITH  THE  CAD  SYSTEM,  BUT 


WHAT  ABOUT  REVISIONS  TO  EXISTING  MANUALLY  PREPARED  DRAWING 
PACKAGES? 

THE  APPROACH  WE  HAVE  TAKEN  IS  DIGITIZING  ON  DEMAND, 

SMALl  REVISIONS  TO  EXISTING  MANUAL  DRAWINGS  ARE  STILL  BEING 
ACCOMPLISHED  IN  A  MANUAL  MODE,  THE  DIGITIZING  COST  IS  TOO 
HIGH  TO  JUSTIFY  FOR  MINOR  UPDATES, 

IF  THE  UPDATE  IS  OF  A  MORE  COMPLEX  NATURE,  BUT  STILL  NOT 
MASSIVE,  IN-HOUSE  DIGITIZING  IS  USED.  BUT  WHAT  ABOUT  DRAWING 
PACKAGES  CONTAINING  MORE  THAN  100  DRAWINGS  WITH  80%  OF  THE 
DRAWINGS  REQUIRING  VARIOUS  DEGREES  OF  REVISIONS?  IN  SUCH  A 
CASE  WE  HAVE  FOUND  OUTSIDE  CONTRACTING  TO  BE  THE  MOST  EFFICIENT, 
QUICK  TURN-AROUND,  ACCURATE  AND  REASONABLE  COST.  WE  HAVE  FOUND 
THAT  THE  AVERAGE  COST  FOR  CONTRACT  DIGITIZING  IS  $75.00  PER 
DRAWING.  CONSIDERING  THAT  MY  IN~HOUSE  HOURLY  RATE  IS  APPROXI¬ 
MATELY  $40.00  PER  HOUR,  THAT  WOULD  MEAN  I  WOULD  HAVE  TO 
COMPLETELY  DIGITIZE  A  DRAWING  ON  AN  AVERAGE  OF  ONE  HOUR  AND 
52  MINUTES.  I  FIND  THIS  TO  BE  A  RATHER  IMPOSSIBLE  TASK.  DOES 
THIS  MEAN  THAT  CONTRACTORS  ARE  ACTUALLY  DIGITIZING  THESE 
DRAWINGS  IN  LESS  THAN  TWO  HOURS  EACH?  OF  COURSE  NOT.  THEN  HOW 
ARE  THEY  ABLE  TO  PERFORM  THE  TASK  AT  THAT  PRICE?  THE  ANSWERS 
ARE  RELATIVELY  SIMPLE.  FIRST  AND  FOREMOST,  THEY  ARE 
GENERALLY  SMALL  JOB  SHOP  HOUSES  WITH  LOW  OVERHEAD.  MANY  HIRE 
VOCATIONAL  TECHNICAL  SCHOOL  AND  COLLEGE  STUDENTS  ON  A  TEMPORARY 
BASIS  USING  SECOND  AND  THIRD  SHIFTS,  THEREBY  GREATLY  REDUCING 
THEIR  LABOR  RATE,  SINCE  THEY  ARE  ONLY  COPYING  DRAWINGS, 
ENGINEERING  EXPERTISE  IS  NOT  REQUIRED. 


ON  THE  SURFACE  THIS  MAY  APPEAR  LIKE  THE  JOB  SHOPS  ARE 
TAKING  ADVANTAGE  OF  THESE  STUDENTS,  QUITE  THE  OPPOSITE,  THE 

STUDENTS  ARE  GAINING  INVALUABLE  EXPERIENCE  ON  A  CAD  SYSTEM, 

I 

AND  AS  WE  W)tLL  ALL  AGREE,  THERE  IS  A  DEFINITE  SHORTAGE  OF 
EXPERIENCED  CAD  OPERATORS.  CONSEQUENTLY,  EVERYONE  IS  GAINING 
FROM  THIS  VENTURE,  WE  ARE  GETTING  DRAWING  PACKAGES  INTO  OUR 
CAD  SYSTEM  AT  A  LOW  COST,  THE  JOB  SHOPS  ARE  MAKING  MONEY  AND 
THE  STUDENTS  HAVE  A  PART-TIME  JOB  GAINING  VALUABLE  CAD 
EXPERIENCE. 

AUTOMATIC  FANNINS.. 

MUCH  HAS  BEEN  SAID  ABOUT  AUTOMATIC  SCANNING  (DIGITIZING). 
I  AM  CONVINCED  IT  WILL  HAPPEN  IN  THE  NEAR  FUTURE,  BUT  NOT 
PRESENTLY  AVAILABLE. 

RASTER  SCANNING  A  DRAWING  OR  MICROFILM  IS  PRESENTLY 
AVAILABLE  WITH  AMPLE  ACCURACY.  BUT  CONVERTING  RASTER  DATA 
TO  INTELLIGENT  VECTOR  DATA  HAS  NOT  BEEN  ACCOMPLISHED  TO  DATE. 
FOR  EXAMPLE!  (1)  CONVERTING  A  RASTER  CIRCLE  TO  A  TRUE 
CIRCULAR  INTERPOLATED  CIRCLE,  (2)  LOCATING  START  POINT  AND 
END  POINTS  OF  LINES,  (3)  INTERPRETING  VARIOUS  THICKNESS  OF 
LINES. 

ALPHA-NUMERICS  PRESENT  AN  EVEN  MORE  CHALLENGING  PROBLEM. 


EVEN  IF  WE  WERE  ABLE  TO  CONVERT  RASTER  TEXT  TO  SHORT  STUBBY 
VECTORS,  IT  WOULD  BE  VIRTUALLY  UNUSABLE.  .  THE  SYSTEM  WOULD  NOT 
RECOGNIZE  IT  AS  TEXT  AND  ALL  THE  DATA  STORAGE  REQUIRED  FOR  THE 


SHORT  STUBBY  VECTORS  WOULD  BE  ENORMOUS.  RECOGNIZE  HOW  MANY 


STUBBY  VECTORS  WOULD  BE  REQUIRED  JUST  TO  DISPLAY  THE  LETTER 
"B" .  THEREFORE,  TEXT  RECOGNITION  IS  REQUIRED.  WHY  NOT  USE 
OPTICAL  CHARACTER  RECOGNITION?  AFTER  ALL  IT  IS  BEING  USED 
QUITE  SUCCESSFULLY  IN  WORD  PROCESSING  TODAY.  THE  DIFFERENCE 
IS  THE  OCR'scEXPECT  TO  SEE  CLEAN  WELL-FORMED  TEXT  WITH  A 
LIMITED  AMOUNT  OF  FONTS.  OLD  MANUALLY  PREPARED  DRAWINGS 
CONTAIN  VARIOUS  SIZES,  FONTS  AND  STYLES,  VERTICAL  LETTERING, 
SLANTED  LETTERS,  AND  TEXT  IMBEDDED  IN  DIMENSIONS.  TO  DATE 
I  KNOW  OF  NO  SYSTEM  THAT  CAN  SOLVE  ALL  OF  THE  ABOVE  PROBLEMS. 

THE  PROBLEM  OF  NOT  BEING  ABLE  TO  ECONOMICALLY  COMMIT 
MANUALLY  PREPARED  DRAWINGS  TO  A  CAD  SYSTEM  IS  ONE  OF  THE 
THREE  MOST  SIGNIFICANT  PROBLEMS  CONFRONTING  CAD  SYSTEMS  TODAY. 

THE  OTHER  TWO  ARE  USER  ACCEPTANCE  AND  DATA  TRANSFER  AMONG 
VENDORS. 

DATA  TRANSFER. 

THIS  PROBLEM  IS  ACTIVELY  BEING  ADDRESSED  TODAY  WITH  MUCH 
SUCCESS.  THERE  ARE  MANY  TRANSLATE  PROGRAMS  BEING  PROMOTED 
TODAY.  I  FEEL  THAT  IGES  (INITIAL  GRAPHIC  EXCHANGE  SPECIFICATION) 
IS  THE  EXCHANGE  SPECIFICATION  THAT  WILL  BECOME  THE  INDUSTRY 
STANDARD  FOR  DATA  EXCHANGE.  IT  SHOWS  GREAT  PROMISE,  AND  HAS  BEEN 


PUBLICLY  DEMONSTRATED  ON  NUMEROUS  OCCASIONS  WITH  ATTRACTIVE 
SUCCESS.  I  AGREE  IT  IS  FAR  FROM  BEING  PERFECT  AND  NEEDS 
MUCH  ENHANCEMENT  AND  SPEED-UP  BUT  AM  CONVINCED  IT  WILL  PREVAIL. 

THE  NEED  FOR  RAPID  ACCURATE  DATA  TRANSFER  BETWEEN 
DIFFERENT  BRANDS  OF  SYSTEMS  IS  IMPERATIVE,  AND  MUST  BE 
ACCOMPLISHED  WITH  OFF-THE-SHELF  SOFTWARE  SUCH  AS  IGES.  SYSTEM 
INCOMPATIBILITY  HAS  BEEN  A  HANDICAP  TO  ME  FOR  A  LONG  TIME. 

FOR  EXAMPLE: 

1.  MOST  OF  OUR  LARGE  TECHNICAL  DATA  PACKAGES  (TDP)  ARE 
DEVELOPED  ON  CONTRACT.  UPON  COMPLETION  OF  THE  CONTRACT,  IT 
IS  OUR  RESPONSIBILITY  TO  MAINTAIN  THIS  TDP.  THE  MAJORITY  OF 
THE  LARGE  CONTRACTORS  TODAY  ARE  DEVELOPING  THE  TDP  ON  A  CAD 
SYSTEM.  BUT,  DUE  TO  INCOMPATIBILITY  THESE  TDP's  ARE 
DELIVERED  ON  HARD  COPY,  SINCE  OUR  SYSTEMS  ARE  INCOMPATIBLE. 

IN  ORDER  TO  TAKE  ADVANTAGE  OF  OUR  CAD  -  l'M  REQUIRED  TO  HAVE 
THE  NEW  TDP  DIGITIZED.  THIS  IS  A  TREMENDOUS  WASTE  OF  TIME 
AND  MONEY. 

WOULDN'T  IT  BE  NICE  IF  COMPATIBILITY  EXISTED  AND  TDP's 
COULD  BE  DELIVERED  ON  A  ROLL  OF  MAGNETIC  TAPE.  UNFORTUNATELY 
TODAY,  THE  ONLY  TIME  THAT  THIS  CAN  BE  ACCOMPLISHED  IS  WHEN  THE 
CONTRACTOR  AND  CRDC  HAVE  COMPATIBLE  SYSTEMS. 

I  AM  SURE  THAT  I  AM  NOT  THE  ONLY  ONE  THAT  SUFFERS  WITH  THIS 
PROBLEM.  FOR  THIS  REASON  I  AM  CONVINCED  THAT  A  COMMON  TRANSLATE 
PROCEDURE  IS  IMPERATIVE  AND  IS  ON  THE  IMMEDIATE  HORIZON. 


2.  EARLIER  I  MENTIONED  ABOUT  CONTRACTING  FOR  DIGITIZING 


OLD  MANUALLY  PREPARED  DRAWINGS,  BECAUSE  OF  THE  SYSTEM 

<zovr**cro+'s 

INCOMPATIBILITY  PROBLEMS,  MY  SOURCE  OF  POTENTIAL  SettftCES  IS 
LIMITED  TO  VENDORS  WITH  THE  SAME  SYSTEM.  CERTAINLY  NOT  AN 
IDEAL  SITUATION, 

<■* 

CONCLUSION. 

I  WOULD  LIKE  TO  THANK  YOU  FOR  ALLOWING  ME  TO  SHARE  SOME 
HIGHLIGHTS  OF  OVER  A  DECADE  OF  CAD  EXPERIENCE.  IN  CONCLUDING 
I  WOULD  LIKE  TO  RELATE  A  HUMOROUS  STORY  ABOUT  A  SERIOUS  STATIC 
PROBLEM  A  USER  ENCOUNTERED.  I  AM  LED  TO  BELIEVE  THAT  THIS  IS 
A  TRUE  STORY  BUT  SINCE  I  DID  NOT  PERSONALLY  ENCOUNTER  IT  I  CANNOT 
VOUCH  FOR  ITS  TRUTH. 

IT  SEEMS  A  USER  HAD  INSTALLED  A  NEW  CAD  SYSTEM  THAT  WAS 
FUNCTIONING  PERFECTLY,  EXCEPT  WHEN  ONE  TRAINEE,  A  YOUNG  LADY, 
TRIED  TO  USE  THE  SYSTEM, 

THE  INSTANT  SHE  TOUCHED  THE  SYSTEM,  A  STATIC  DISCHARGE 
OCCURRED  AND  THE  SYSTEM  CRASHED.  THE  VENDOR  TRIED  EVERYTHING 
TO  SOLVE  THE  PROBLEM;  STATIC  MATS  WERE  INSTALLED,  MORE  GROUND 
WIRE  ADDED,  ROOM  HUMIDITY  WAS  INCREASED  ALL  TO  NO  AVAIL. 

AFTER  MUCH  INVESTIGATING,  THE  SOURCE  OF  THE  PROBLEM  WAS  FINALLY 
REVEALED.  IT  SEEMS  THIS  YOUNG  LADY  HAD  A  LONGING  FOR  PURE  SILK 
UNDERPANTS,  AND  THIS  WAS  THE  SOURCE  OF  THE  STATIC  BUILDUP. 
SWITCHING  UNDERPANTS  OF  ANOTHER  MATERIAL  SOLVED  THE  PROBLEM. 

THE  ONLY  QUESTION  THAT  REMAINS  UNANSWERED  IS  HOW  DID  THEY 
DISCOVER  THAT  THE  YOUNG  LADY  WAS  WEARING  PURE  SILK  UNDERPANTS? 


COMPUTER  PROGRAM  SPECIFICATIONS 
AND 

ASSOCIATED  DOCUMENTATION 
by 

Raymond  J.  Schmitt 
Kearfott  Division 
The  Singer  Company 
Wayne,  New  Jersey 

INTRODUCTION 

A  relatively  few  years  ago,  an  employee  charged  with  responsibility 
for  the  identification,  documentation  and  release  of  computer 
program  media  at  my  company  included  in  his  description  of  a 
specific  software  package  the  term  "concatenation"  (slide  1) .  It 
was  a  new  term  to  both  of  us.  Since  the  word  had  been  used  by  one 
of  our  more  erudite  doctoral  scholars,  my  question  of  its  use  was 
not  to  its  accuracy  but  rather,  were  we  establishing  a  new  line  of 
jargon?  Of  course,  the  word  has  endured,  its  meaning  clearly 
showing  the  closely  linked  elements  of  a  computer  program.  The 
reason  I  recall  it,  is  that  it  dates  for  me  the  time  period  when  my 
company,  as  well  as  industry  as  a  whole,  began  to  address  software 
as  software,  rather  than  in  terms  of  hardware  standards. 

The  evolution  of  software  documentation,  like  all  new  standard 
practices,  suffered  from  a  variety  of  growing  pains.  In  the  early 
days,  software  engineering  personnel  demonstrated  little  knowledge 
of  configuration  management  practices.  Computer  media  on  which  data 


was  stored  (usually  card  decks  or  tapes)  were  most  often  filed  in  a 
software  engineer's  desk  drawer  (slide  2).  Each  engineering  group 
developed  its  own  standards  for  desk-drawer  identification  and 
control.  The  only  types  of  documentation  conceived  were  Programmers 
Manuals,  providing  internal  design  data  for  members  of  the  software 
engineering  group,  and  Users  Manuals  for  customer  application  of  a 
given  program.  In  the  event  an  individual  left  his  group  or 
company,  a  large  proportion  of  the  engineering  configuration 
knowledge  for  his  project  left  with  him.  Only  practical,  immediate 
use  factors  were  considered  in  determining  the  scope  of 
documentation  produced. 

As  applications  began  to  include  hardware  test  functions,  and  then 
overall  system  mission  requirements,  the  "need  to  know"  and  to 
guarantee  product  performance  and  uniformity  surpassed  the  fear  of 
delving  into  the  black-magic  wizardry  associated  with  computer 
programs.  Along  came  our  hardware-drafting-oriented  configuration 
standards  people  (slide  3}...  eager  to  subdue  the  software  beast  and 
chain  it  to  the  hardware  practices  that  had  served  so  well  for  so 
long.  Heard  the  loudest  were  the  advocates  of  software  assembly 
drawings,  software  schematics,  and  software  parts  lists,  all  to  be 
prepared  in  accordance  with  MIL-STD-100.  The  beast  was  recognized, 
but  the  feeble  attempts  to  handle  it  were  inadequate. 

Much  water  has  since  gone  over  the  dam.  Hardware  and  software 
people  have  learned  much  of  each  others  problems  and  the  languages 
needed  to  communicate  with  each  other.  In  fact,  the  necessity  to 
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deal  with  firmware  and  the  use  of  computers  as  engineering, 
drafting,  and  manufacturing  tools  has  continued  to  increase  the 
interchange  and  application  of  knowledge  between  these  disciplines. 
We  now  find  software  engineering  and  quality  assurance  personnel  so 
engrossed  in  configuration  management  and  test  practices  that  the 
pendulum  has  swung  clearly  into  a  new  danger  zone  (slide  4) .  Ten 
years  ago  formal  documentation  of  software  contributed  only  between 
5  and  10%  to  my  company's  engineering  documentation  page-count. 
Today,  it  accounts  for  75  to  80%.  I'm  sure  we  represent  the  norm 
rather  than  the  unusual  for  companies  in  similar  high-technology 
product  areas  that  design  and  produce  programmable  types  of 
equipment.  Ten  years  ago  documentation  was  insufficient.  The  first 
challenge  addressed  for  the  '80's  has  been  "tailoring”  (slide  5)  ... 
tailoring  the  extent  and  form  of  documentation  to  its  mission 
requirements.  The  second  challenge  is  the  continued  development  of 
computer-aided  resources  to  produce  the  detailed  segments  for 
computer  program  specifications  and  validation  documentation. 

MILITARY  PRACTICES 

Let's  take  a  look  at  software  Government  practices  over  the  years. 
The  first  major  attempt  at  establishing  documentation  practices  for 
computer  programs  were  initiated  with  the  Air  Force's  AFSCM  375-1 
and  the  Navy's  WS8506.  Evolution  has  progressed  to  the  Air  Force's 
MIL-STD-483/ 490  and  the  Navy's  MIL-STD-1679 .  Most  recently,  much 
effort  has  been  expended  on  a  proposed  joint  standard,  designated 
DOD-S TD-SDS  during  its  development  phase. 


My  company  selected  the  MIL-STD-483/490  approach  for  its  standard 
practice  (slide  6) .  In  1970  when  MIL-STD-483  was  published  by  the 
U.S .  Air  Force,  it  included  updates  to  MIL-STD-490,  which  had  been 
prepared  for  DOD  and  released  in  1969. 

These  updates  were  supposed  to  be  temporary,  in  effect  until 
MIL-STD-490  would  be  revised.  Then,  appropriate  matter  would  be 
included  in  the  MIL-STD-490  update  and  deleted  from  MIL-STD-483.  In 
actuality,  when  a  major  revision  was  established  for  computer 
program  documentation  in  1979,  it  was  more  convenient  to  revise 
MIL-STD-483  to  incorporate  the  latest  practices  since  it  was  an  Air 
Force  document.  MIL-STD-490  has  yet  to  be  officially  revised  in 
substance;  however,  substantial  revisions  have  been  proposed  as 
Notice  3  by  the  SDS  project  team. 

The  approach  of  establishing  baselines  for  phases  of  procurement  in 
MIL-STD-490/483  has  been  consistent  with  practices  used  tor  hardware 
configuration  items.  When  software  Computer  Program  Configuration 
Items  (CPCI's)  are  allocated  as  functional  elements  of  systems  or 
subsystems,  a  Development  or  Part  I  specification  is  prepared  (slide 
7)  to  specify  design  and  development  criteria.  In  software,  this 
item  basically  provides  the  mathematical  equations  to  be  solved  by 
the  programmer,  and  the  validation  requirements  to  qualify  the  final 
product.  This  specification  forms  the  Development  Baseline  for 
design  and  development,  which  is  the  controlling  baseline  at  the 
Preliminary  Design  Review  (PDR)  conducted  by  the  seller  for  buyer 
approval. 


The  Product  or  Part  II  Specification  (slide  8)  establishes  the 
Product  Baseline.  This  specification  provides  definition  of  the 
detailed  as-coded  computer  program -prepared  by  programmers.  It  also 
establishes  the  verification  procedures  applicable  to  the 
reproduction  of  the  CPCI  or  any  pertinent  element  of  the  CPCI. 
General  program  requirements  are  covered  in  paragraphs  3.1  through 
3.9  of  the  MIL-STD-483  Product  Specification.  A  preliminary  Product 
Specification  is  baselined  at  a  Critical  Design  Review  at  which  time 
all  design  approaches  to  program  functional  elements  are  approved. 

Paragraphs  3.10  and  3.11  of  this  document  provide  the  actual 
detailed  design  descriptions,  including  such  items  as  flow  charts 
and  listings  for  each  component  of  the  as-designed  program.  As  such 
these  sections  can  be  compared  to  the  set  of  drawings  for  hardware. 
They  are  completed  for  the  Physical  Configuration  Audit  (PCA) 
conducted  prior  to  shipment  of  the  CPCI  product. 

MIL-STD-1679  basically  corresponds  to  this  same  MIL-STD-490/483 
baseline  management  approach  (slide  9).  However,  the  Development 
Baseline  specification  is  entitled  Program  Performance 
Specification,  and  the  Product  Baseline  is  established  by  two 
documents.  The  Program  Design  Specification  establishes  general 
design  requirements  which  can  be  finalized  at  the  Critical  Design 
Review.  The  Program  Description  Document  corresponds  to  the 


detailed  (coded)  program  and  is  finalized  prior  to  first  article 
delivery  or  at  PCA.  This  system  is  geared  to  formalizing  specific 
documents  when  specific  procurement  milestones  are  achieved. 

Other  practices  have  also  been  milestone  sensitive.  For  example  the 
Air  Force  Milestone  Notation  System  in  accordance  with  Exhibit  61- 
47B  (slide  10).  NASA  practice  (slide  11)  also  provides  milestone 
sensitive  design  documentation  as  did  the  Navy's  WS8506  (slide  12). 

The  latest  proposed  practice  is  provided  in  DOD-STD-SDS  (slide  13) . 
In  addition  to  required  documents  for  development  and  product 
baselines,  optional  documentation  previously  omitted  in  MIL-STD- 
490/483  has  been  added.  In  this  approach,  the  product  baseline  is 
established  in  two  required  phases,  in  the  manner  provided  by  MIL- 
STD-1679 .  This  enables  preparation  and  baselining  of  documentation 
at  logical  milestones  associated  with  the  establishment  of  general 
requirements  and,  later,  when  the  CPCI  is  fully  coded. 

Additionally,  the  new  standard  and  proposed  revisions  to  Data  Item 
Descriptions  integrate  the  procurement  of  CPCI's  into  MIL-STD-483 
and  MIL-STD-490  configuration  management  practices.  In  fact, 
substantive  updates  to  both  of  these  standards  are  finally  addressed 
by  the  SDS  recommendations.  Of  greater  importance,  this  standard 
evidences  a  good  deal  of  input  by  software  programming  specialists. 
It  provides  for  alternate  tools  for  describing  programs  that  enable 
the  design  to  dictate  documentation  details,  rather  than  document 
practice  to  limit  design  tools. 


MY  COMPANY* S  STANDARD  PRACTICES 

As  discussed  earlier,  my  company's  internal  practices  follow  the 
MIL-STD-490/483  approach  for  specifications.  A  list  of  document 
types  used  for  software  is  provided  by  slide  14.  These  documents 
are  employed  to  the  extent  imposed  by  design  disclosure  project 
requirements  (slide  14).  In  any  event,  note  that  when  a  computer 
program  medium  (for  example,  magnetic  tape,  paper  tape,  discs,  etc.) 
is  shipped,  it  must  be  released  to  a  controlled  central  records 
department  which  is  charged  with  the  reproduction  of  the  computer 
program  medium  and  its  corresponding  documentation  for  shipment. 
Whether  shipped  or  not,  each  computer  program  medium  can  only  be 
released  in  a  set  that  includes  the  medium,  a  Computer  Program  Media 
Document  and  a  Version  Description  Document.  The  Computer  program 
medium  itself  is  assigned  a  part  number  and  controlled  as  a 
hardware-type  item.  Changes  to  the  program  contained  on  the 
computer  program  medium  require  assignment  of  a  new  part  number. 

The  Computer  Program  Media  Document  (slide  16)  specifies  the 
physical  characteristics  of  the  computer  program  media;  provides  a 
base  for  a  significant  dash-number,  part-identification  system;  and 
specifies  computer  program  media  reproduction  procedures. 

The  Version  Description  Document  (VDD)  (slide  17)  describes  the 
software  resident  on  the  computer  program  media  and  specifies  the 
differences  between  the  current  program  version  and  other  program 
versions.  Additionally,  all  known  bugs  and  functions  which  have  not 
been  implemented  in  the  current  program  version  are  delineated. 
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My  company  also  creates  the  following  documents: 

•  Users  Manuals  (slide  18) 

•  Validation  Test  Plans  (slide  19) 

•  Validation  Procedures  (slide  20) 

•  Validation  Data  Packages  (slide  21) 

•  Program  Listing  Documents 

HARDWARE  EMBEDDED  SOFTWARE 

Documentation  discussed  thus  far  has  dealt  with  software  CPCI's  and 
the  computer  program  media  used  for  storage  and  delivery  of  these 
CPCI's.  There  are  other  related  areas  of  software  that  require 
documentation  at  different  levels.  The  first  is  microcode,  the 
software  normally  implemented  in  semiconductor  devices  that  provides 
operating  characteristics  to  a  functional  end-item  of  hardware.  A 
change  to  this  software  changes  the  capabilities  of  the  items  in 
which  it  is  housed.  It  can  be  described  as  the  basic  brains  of  a 
programmable  unit,  rather  than  the  information  applied  to  the  brains 
for  a  specific  application.  Whereas  a  software  package  is  intended 
for  processing  by  a  computer,  a  microcode  program  is  the  processOR. 

Devices  used  for  microcode  and  other  hardware-related  applications 
are  hardware-embedded.  Software  resident  in  these  devices  is 
properly  termed  "firmware."  The  hardware  configuration  design 
disclosure  in  such  instances  is  incomplete  without  firmware 


definition.  Since  these  firmware  items  are  intended  for  permanent 
storage,  they  are  normally  implemented  by  non-alterable 
semiconductor  devices,  that  is  by  Read  Only  Memory  Devices  (ROM's) 
or  Programmable  Read  Only  Memory  Devices  (PROM's). 

My  company  documents  ROM's  and  PROM's  using  control  drawing 
practices.  We  procure  a  ROM  with  a  Specification  Control  Drawing 
(SCD)  that  references  a  Truth  Table  (slide  22)  for  each  memory 
device  tabulated  on  the  SCD.  For  PROM's,  which  are  programmed  in- 
house,  we  procure  the  unprogrammed  memory  device  with  an  SCD.  Then, 
an  Altered  Item  Drawing  (AID)  is  prepared,  which  references  the 
purchased  item  by  SCD-based  part  number,  and  specifies  programming 
in  accordance  with  a  Truth  Table.  These  Truth  Tables  provide  the 
actual  binary  configuration  (that  is  the  BIT  content  at  each  address 
within  the  memory  device) .  The  hardware  design  disclosure  is 
thereby  complete.  For  manufacturing  purposes,  the  contents  of  the 
Truth  Table  are  stored  on  a  controlled  computer  program  medium  which 
is  used  in  a  Loader/Verifier  unit  that  programs  the  memory  device. 

Separately,  for  internal  control  purposes,  flow  charts  are  prepared 
for  microcode  programs.  These  internal  documents  are  referenced  in 
a  Version  Description  Document.  They  enable  a  Programmer  to  revise 
microcode  software  when  .required,  either  for  a  revised  hardware 
baseline  or  for  new  applications. 

• 
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In  today's  hardware  designs,  semiconductor  devices  are  also  used  to 
implement  CPCI  software.  In  this  case,  since  software  is  subject  to 
change,  the  firmware  device  is  normally  an  EPROM,  that  is  an 
eraseable  PROM.  For  such  applications,  my  company  usually  populates 
a  Memory  Circuit  Card  Assembly  with  the  sum  total  of  EPROM's 
required  to  implement  the  CPCI  along  with  input/output  and  control 
circuitry.  In  this  case,  the  entire  program  is  loaded  onto  the 
circuit  card  via  card  connectors  after  part  population.  A  support 
PROM  Generator  Program  is  used  to  organize  the  CPCI  object  code  to 
enable  loading  by  Loader/Verifier  equipment.  We  now  have  the  case 
of  a  fully  documented  software  program,  that  also  requires 
documentation  as  firmware  when  procurement  of  spare  programmed 
circuit  cards  is  required.  To  accomplish  this,  my  company  creates  a 
higher-level  assembly  drawing  (slide  23)  and  its  associated  parts 
list.  In  essence,  this  circuit  card  assembly  documentation 
references  a  Truth  Table  (listing)  that  specifies  the  entire 
contents  in  EPROM  that  are  loaded  onto  an  unprogrammed  circuit  card, 
and  marked  to  provide  the  CPCI  version  number  associated  with  the 
contents  in  memory. 


CHALLENGES  FOR  THE  '80's 


Let's  take  a  look  at  the  challenges  on  the  horizon: 

•  First  -  Let's  smooth  out  the  wrinkles  in  DOD-STD-SDS  and  get 
it  published.  Let's  go  a  step  further  and  ensure  that  this 
single  approach  is  used  by  all  services.  In  accordance  with 
the  SDS  project,  let's  update  the  entire  series  of 
configuration  management  and  documentation  preparation 
standards  to  purge  MIL-STD-483  of  requirements  which  properly 
belong  in  other  DOD  documents. 

•  Second  -  Let's  update  DOD-STD-lOO  to  cover  hardware 
documentation  requirements  for  embedded  software  (firmware) . 

•  Third  -  Let's  get  the  programmers  even  more  involved  in 
documentation  practices.  Specifically  let's  learn  from  the 
techniques  used  in  computer-aided  engineering,  drafting  and 
manufacturing.  Certainly  support  software  could  be  written 
to  derive  much  or  all  of  the  detailed  design  information  from 
the  as-coded  program.  Literally  hundreds  of  pages  are  used  to 
describe  these  details  for  a  major  CPCI. 

•  Fourth  -  What  about  developing  automatic  validation 
procedures,  again  assembled  via  support  software  programs. 

At  my  company,  we  released  a  5,000  page  Validation  Plan  last 
year  for  a  major  CPCI. 

In  summary,  software  documentation  is  directly  related  to  automatic 
data  processing  (ADP) ;  all  avenues  for  use  of  ADP  should  be  examined 
for  the  assembly  of  this  documentation. 


EN-A-TION 


OF  CAT  IS  THIS  ? 


(SLIDE  1) 


(SLIDE  2) 


SINGER-KEARFOTT 

MIL-STD-490 

MIL-STD-483 

Computer  Program 

Development  Specification 

Type  B  5 

Computer  Program 

Development 

Specification 

Computer  Program 
Configuration  Item 
Specification 
(Part  I) 

Computer  Program 

Product  Specification 

Type  C5 

Computer  Program 

Product 

Specification 

Computer  Program 
Configuration  Item 
Specification 
(PART  II) 

(SLIDE  6) 


COMPUTER  PROGRAM  DEVELOPMENT  SPECIFICATIONS 


•  Describes  all  requirements  necessary  to  design  the  required 
computer  program  in  terms  of  performance.  It  provides  the 
logical  detailed  descriptions  of  the  performance  requirements 
of  a  digital  computer  program. 


•  Serves  as  the  documentation  necessary  to  enable  the  design, 
development  and  testing  of  a  computer  program. 


•  Prepared  prior  to  the  development  of  the  computer  program  by 
personnel  who  have  knowledge  of  the  system  and  its  operational 
concepts,  but  who  do  not  necessarily  have  detailed  knowledge  of 
programming  terminology. 


•  Reflects  performance  criteria  in  terms  of  operational,  functional 
and  mathematical  language. 


•  Baseline  document  for  subsequent  software  efforts. 


•  Part  I  Specification,  Type  B5. 


•  Format  per  MIL-STD-483/MIL-STD-490. 
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COMPUTER  PROGRAM  PRODUCT  SPECIFICATIONS 


■  Specifies  design  description  of  the  computer  program  based  on  the 
performance  requirements. 


•  Prepared  by  personnel  with  an  intimate  knowledge  of  digital 
computer  system  architecture  and  programming,  as  well  as  a  good 
understanding  of  the  operational  concepts  in  the  overall  system. 


•  Written  in  programming  terminology;  translates  the  Development 
Specification  requirements  into  detailed  technical,  rather  than 
functional,  terms. 


•  Provides  a  complete  technical  description  of  all  computer 
subprogram  functions,  structures,  operating  environments, 
constraints,  data  organization  and  control  flows,  for  the  subject 
computer  program. 


•  Serves  as  the  essential  instrument  for  ongoing  and  subsequent 
uses,  including  diagnosing  troubles,  making  adaption  changes, 
designing  and  implementing  minor  or  major  modifications  to  the 
system,  and  facilitating  rapid  familiarity  with  the  subprogram 
functions  by  new  personnel. 


•  Part  II  Specification,  Type  C5. 


•  Format  per  MIL-STD-483/MIL-STD-490. 


(SLIDE  8) 
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MIL-STD-483/490  VS  MIL-STD-1679 


MIL-STD-483/490 


MIL-STD-1679 


COMPUTER  PROGRAM  DEVELOPMENT  PROGRAM  PERFORMANCE 

SPECIFICATION  (PART  I)  SPECIFICATION 


COMPUTER  PROGRAM  PRODUCT 
SPECIFICATION  (PART  II) 


PROGRAM  DESIGN 
SPECIFICATION  (GENERAL 
REQUIREMENTS) 


PROGRAM  DESCRIPTION 
DOCUMENT  (AS-CODED 
PROGRAM  DETAILS) 


(SLIDE  9) 


SINGER-KEARFOTT  PRACTICE  VS  MILESTONE  NOTATION 
IN  ACCORDANCE  WITH  SSD  EXHIBIT  61-47B 


SINGER-KEARFOTT 

MILESTONE  NOTATION 

Computer  Program 

Development  Specif icatidn 

Milestone  1:  Requirements 

Milestone  2:  Implementation 
Concepts 

Computer  Program 

Product  Specification 

Milestone  3:  Interface 

Definitions 

Milestone  4:  Program 

Design 

Computer  Program 

Milestone  6:  Integration 

Validation  Plan 

Test  Procedure 

r 

Computer  Program 

Validation  Procedure 
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SINGER-KEARFOTT  PRACTICE  VS  NASA  SPACE  SHUTTLE  STANDARD 
IN  ACCORDANCE  WITH  JSC  07700,  VOLUME  XVIII,  BOOK  3 


SINGER-KEARFOTT 

NASA 

Computer  Program  Development 
Specification 

Software  Requirements 

Specif ication 

Preliminary  Software  Design 
Specification 

Computer  Program  Product 
Specification 

Detailed  Software  Design 
Specification  (Code  To) 

Detailed  Software  Design 
Specification  (As-Built) 

Computer  Program  Validation 
Plan 

Software  Test  Requirements 

Software  Test  Plan 

Computer  Program  Validation 
Data  Package 

Software  Verification  Test 
Report 
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SINGER-KEARFOTT  PRACTICE  VS  WS8506 


SINGER-KEARFOTT 


WS8506 


Computer  Program  Development 
Specification 


Computer  Program  Performance 
Specification  (CPPS) 


Computer  Program  Design 
Specification  (CPDS) 


Computer  Program 
Product  Specification 


Data  Base  Design  Document 


Computer  Subprogram  Design 
Documents  (CSDD) 


Computer  Program 


Computer  Program  Test  Plan 


Validation  Plan 


Computer  Program 
Validation  Procedures 


Computer  Program  Test 
Procedures 


Computer  Program 
User's  Manual 


Computer,  Program 
Operators  Manual 
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CURRENT  MIL-STD-490/483  VS  DOD-STD-SDS  2/ 


MIL-STD-490/483 

DOD-STD-SDS  490  REVISIONS 

TYPE  B5  CPDS 

TYPE  B5 

o  TYPE  B 5a  -  SOFTWARE  REQUIREMENTS 

COMPUTER  PROGRAM 

SPECIFICATION 

DEVELOPMENT  SPECIFICATION 

(CPDS ) 

O  TYPE  B5b  -  INTERFACE  REQUIREMENTS^/ 

SPECIFICATION 

TYPE  C5  CPPS 

TYPE  C5 

o  TYPE  C5a  -  SOFTWARE  TOP  LEVEL 

COMPUTER  PROGRAM 

DESIGN  DOCUMENT 

PRODUCT  SPECIFICATION 

(CPPS) 

i 

1 

O  TYPE  C5b  -  SOFTWARE  DETAILED 

i 

DESIGN  DOCUMENT 

j 

O  TYPE  C5c  -  DATA  BASE  2] 

! 

DESIGN  DOCUMENT 

O  TYPE  C5d  -  INTERFACE  DESIGN  2] 

i _ 

DOCUMENT 

NOTE  1  -  DOD-STD-SDS  PRACTICES  ARE  ACHIEVED  THROUGH  CHANGES  TO 
MIL-STD-490/483  AND  OTHER  EXISTING  DATA  ITEMS 


2  -  OPTIONAL  DOCUMENTATION 


(SLIDE  13) 


DOCUMENT  TYPES 

1.  COMPUTER  PROGRAM  MEDIA  DOCUMENT 

2.  COMPUTER  PROGRAM  VERSION  DESCRIPTION  DOCUMENT  (VDD) 

3.  COMPUTER  PROGRAM  USERS  MANUAL 

4.  COMPUTER  PROGRAM  DEVELOPMENT  SPECIFICATION 

5.  COMPUTER  PROGRAM  PRODUCT  SPECIFICATION 

6.  COMPUTER  PROGRAM  VALIDATION  PLAN 

7.  COMPUTER  PROGRAM  VALIDATION  PROCEDURES 

8.  COMPUTER  PROGRAM  VALIDATION  DATA  PACKAGE 

9.  COMPUTER  PROGRAM  LISTING  DOCUMENT 


STANDARD  LEVELS  OF  DOCUMENTATION 


A.  FULL  DISCLOSURE 

B.  EXPANDED  DISCLOSURE 

C.  NORMAL  (USER  LEVEL)  DISCLOSURE 

(SLIDE  14) 
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(2)  MEDIA  DOCUMENT  AND  VERSION  DESCRIPTION  DOCUMENT  MUST  BE  PREPARED  PRIOR  TO  RELEASE  OF 
PROGRAM  TO  FILE. 


COMPUTER  PROGRAM  MEDIA  DOCUMENT 


•  Provides  for  identification  and  configuration  control  for  a  media 
(i.e.,  paper  tape,  magnetic  tape,  discs,  cassettes,  etc.) 

•  Specifies  the  Part  Number  for  the  media. 

•  Specifies  physical  description  of  the  media. 

•  Lists  all  versions  of  the  media. 

•  Specifies  general  content  of  each  file. 

•  Describes  the  identification  label  on  the  media. 

•  Specifies  procedure  for  reproducing  the  media  and  the  method  of 
verifying  reproduced  copy. 

(SLIDE  16) 

VERSION  DESCRIPTION  DOCUMENT 

•  Provides  functional  outline  of  the  computer  program  capability. 

•  Specifies  differences  between  current  version  and  other  versions 
similar  in  content. 

•  Lists  all  known  bugs  and  functions  which  have  not  yet  been 
implemented. 

•  Gives  recommendations  for  proper  operation  of  the  system  in  the 
presence  of  these  bugs  or  anomalies. 

•  Repository  for  information  relating  to  the  installation  of  the 
program  at  the  users  facility. 

•  A  convenient  repository  for  miscellaneous  user  information. 

•  A  separate  VDD  is  required  for  each  released  program  version. 

(SLIDE  17) 
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COMPUTER  PROGRAM  USERS  MANUAL 


•  Presents  procedures  for  executing  the  computer  program  and 
interpreting  its  outputs. 


•  In  hands-off  environment,  (e.g.,  a  batch  run  in  a  large  computer 
center)  the  document  describes: 

a.  the  logic  functions  of  the  program. 

b.  the  techniques  for  proviJing  input  to  the  program. 

c.  any  information  required  to  interpret  the  output. 


•  In  hand-on  environment,  (e.g.,  the  control  program  in  a  realtime 
data  collection  and  reduction  system)  document  describes  the 
operating  instructions,  in  addition  to  the  items  specified  in 
hand-off  environment. 


•  Provides  monitoring  procedure  of  the  computer  program  while  in 
operation. 


•  Provides  trouble  and  malfunction  indications. 


•  Specifies  procedures  to  restart  the  system  operation  after  an 
abort  or  interruption  in  the  operation  of  the  computer  program. 


(SLIDE  18) 


•  Contents  governed  by  the  testing  requirements  and  criteria 
specified  in  the  CPCI  Development  Specification. 

•  Specifies  method  and  content  for  each  program  test  activity. 

•  Identifies  level  of  testing  and  the  specific  functions  or 
subprograms  that  are  involved  in  the  test,  including: 

a.  Subprogram  testing 

b.  Integration  testing 

c.  Acceptance  testing 

d.  System  testing 

•  Provides  objectives  for  each  test. 

•  Summarizes  test  methods  and  type  of  system  environment  to  be 
used . 

•  Specifies  hardware  requirements  necessary  for  conducting  the 
test,  i.e.,  computer  complex  with  its  peripheral  equipment  and 
other  supporting  equipment  that  interfaces  with  the  computer 
complex . 

•  Gives  supporting  software  requirements. 

•  Specifies  precise  functions  to  be  tested. 

•  Provides  quality  assurance  requirements. 


(SLIDE  19) 


COMPUTER  PROGRAM  VALIDATION  PROCEDURES 


•  Developed  from  the  Validation  Plan. 


•  Presents  detailed  instructions  for  setup,  operation  and  evaluation 
of  results  for  each  level  of  testing. 

•  Procedures  are  intended  for  use  by  personnel  responsible  for  the 
verification  of  program  content  and  operation,  from  initiation  to 
completion  of  program  development. 


•  Describes  the  total  equipment,  manpower,  computer  programs  and 
supporting  documentation  required  for  operation. 


•  Specifies  detailed  procedure  covering  all  aspects  of  operation. 

•  Provides  criteria  for  satisfactory/unsatisfactory  operation. 


(SLIDE  20) 


COMPUTER  PROGRAM  VALIDATION  DATA  PACKAGE 


•  Depository  for  data  generated  during  the  testing  of  the  computer 
program  to  substantiate  successful  execution  of  the  validation 
tests. 


•  Each  version  of  the  computer  program  is  required  to  be  validated 
and  therefore  is  required  to  have  a  Validation  Data  Package. 


COMPUTER  PROGRAM  LISTING  DOCUMENT 


•  Consists  of  a  source  listing  of  the  computer  program. 

•  Source  language  to  be  the  language  in  which  the  program  is 
developed  and  maintained. 

(SLIDE  21) 
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TRUTH  TABLE  KEARFOTT  DIVISION  88818  A398A _ 

LITTLE  FALLS,  N.J.  SIZE  A  SCALE  NONE 

DATE  83/12/12 

CONTRACT  NO  NO -CONTRACT -YET  DATA  RIGHTS  REVIEW  05223 (NP)  SHEET  1 

ADRS  CONTENT...  (LEAST  SIGNIFICANT  BIT  ON  RIGHT  H  =  5  VOLTS,  L  =  0  VOLTS) 

0000  HHHHHLLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHHHL  HHHHHHHH  HHHHHHLH  HHKHHHHH 

0008  HHHHLLLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHHHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0016  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0024  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0032  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0040  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0048  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0056  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0064  HHHHHLLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0072  HHHHHHLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0080  HHHHLLLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0088  HHHHHHLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0096  HHHHHLHH  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0104  HHHHHHLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0112  HHHHLLLL  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0120  HHHHHHLL  HHKHHHHH  HHHHHHLH  HHHHHHHH  HHHHHLHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0128  HHHHHHLH  HHHHLLHL  HHHHLLHH  HHHHLLHL  HHHHLLLH  HHHHLLHL  HHHHLLHH  HHHHLLKL 

0136  HHHHLHLL  HHHHLLHL  HHHHLLHH  HHHHLLHL  HHHHLLLH  HHHHLLHL  HHHHLLHH  HHHHLLHL 

0144  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0152  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0160  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0168  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0176  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0184  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0192  HHHHHLLL  HHHHHLLH  HHHHHLHL  HHHHHLHH  HHHHHHLL  HHHHHHLH  HHHHHHHL  HHHHHHHH 

0200  HHHHLLLL  HHHHLLLH  HHHHLLHL  HHHHLLHH  HHHHLHLL  HHHHLHLH  HHHHLKHL  HHKHLHHK 

0208  HHHLHLLL  HHHLHLLH  HHHLHLHL  HHHLHLHH  HHHLHHLL  HHHLHHLH  HHHLHHHL  HHHLHHHK 

0216  HHHLLLLL  HHHLLLLH  HHHLLLHL  HHHLLLHH  HHHLLHLL  HHHLLHLH  HHHLLHHL  HHHLLKHK 

0224  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0232  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0240  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0248  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0256  HHHHHHLH  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHHHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0264  HHHHHLLH  HHHHHHHH  HHHHHHLH  HHHHHHHH  HHHHHHHL  HHHHHHHH  HHHHHHLH  HHHHHHHH 

0272  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0280  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0288  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0296  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0304  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0312  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0320  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0328  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0336  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 

0344  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH  HHHHHHLH 
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ON-LINE  CONFIGURATION  MANAGEMENT 
AND  ENGINEERING  DATA 


Charles  3.  Borum 

Configuration  Management  Officer 
PERSHING  Project  Manager's  Office 
U.  S.  Army  Missile  Command 
Redstone  Arsenal,  Alabama  35898 

Since  1970,  Martin  Marietta  Orlando  Aerospace  and  the  U.  S.  Army  Pershing  Project 
Configuration  Management  Office  have  been  working  on  several  computerized  systems  to 
be  used  by  technical  personnel  for  creating  engineering  designs,  engineering  parts  lists, 
and  identifying  engineering  configurations.  Increased  productivity,  improved  accuracy, 
faster  response  time,  and  ease  of  access  were  primary  objectives  in  the  design  of  these 
systems.  The  ultimate  aim  is  to  deliver  all  data  in  digital  format,  thereby  eliminating  the 
need  for  hard  copy  distribution  of  drawings,  microfilm,  or  other  engineering  and 
configuration  management  data.  The  major  systems  utilized  are  briefly  described  below: 

o  DOCUMENTATION  INFORMATION  AND  CONTROL  SYSTEM  (DIACS)  is  an  on-line 
Information  Management  System  (IMS)*  data  base  that  contains  a  complete  catalog 
of  ir.-house-designed  parts  plus  vendor  parts,  materials,  processes,  and  specifica¬ 
tions  required  by  the  designer  to  develop  Bills  of  Material  for  designs.  DIACS 
maintains  a  complete  definition  of  the  design  configuration,  as  proposed.  It  also 
tracks  and  updates  the  configuration  as  the  design  progresses,  is  completed,  and  is 
released.  DIACS  assigns  document  and  part  numbers,  advance  change  numbers,  and 
document  revision  letters  and  maintains  status  on  these  elements  throughout  the  life 
of  the  document.  The  system  provides  the  designer  with  a  technique  for  calculating 
the  cost  and  weight  of  assemblies  and  summing  them  to  the  end  item  level.  Other 
outputs  available  to  aid  the  designer  as  well  as  management  are:  Generation 
Breakdowns,  Consolidated  Bills  of  Material,  Where-Used  Data  (from  next  assembly 
to  end  item).  Approved  Parts,  Material  and  Process  Listings  (by  project),  and  a 
wealth  of  statistical  data  used  to  monitor  engineering  activity  and  aid  in  proposal 
planning  or  pricing.  DIACS  provides  automated  transfer  of  data  to  the 
Manufacturing  Bill  of  Material  System,  the  Manufacturing  Process  Plan  System,  the 
Inventory  and  Order  Management  Systems,  and  several  computer  graphic  systems. 
There  are  over  400  cathode  ray  tube  (CRT)  terminals  and  60  printers  available  to 
access  the  system.  The  host  central  processing  unit  (CPU)  for  DIACS  is  an  IBM  3033. 

o  COMPUTER  AUGMENTED  DESIGN  AND  MANUFACTURING  (CADAM)**  is  used 
primarily  for  two  dimensional  mechanical  drawings.  It  also  has  the  capability  of 
producing  machine  control  (N/C)  tapes  or  discs  from  the  engineering  design  for  use 
in  the  Manufacturing  tooling  process. 

o  SCI-CARDS+  is  used  to  design  printed  wiring  boards.  It  is  a  very  powerful  program 
that  requires  the  engineer  to  define  only  the  types  of  components,  connect  points, 
and  board  sizes.  The  system  places  the  components  and  does  all  the  circuit  routing. 
By  direct  output  or  post- processing,  the  system  produces  the  circuit  artwork, 
assembly  drawing,  drill  drawing,  and  marking  drawing.  To  aid  manufacturing,  the 
post -processor  also  produces  N/C  tapes  or  disks  for  automatic  drilling  and  routing  of 
the  board  and  for  the  insertion  of  component  parts. 

♦IMS  is  a  registered  trademark  of  the  International  Business  Machine  Company 
**CADAM  is  a  registered  trademark  of  the  Lockheed-California  Company 
+50- CARDS  is  a  registered  trademark  of  Scientific  Calculations,  Inc.,  Rochester,  New 
York 
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COMPUTERVISION  (CV)*  is  used  to  prepare  three  dimensional  drawings  for  use  in 
handbooks  and  where  a  trimetric  engineering  drawing  is  needed  for  clarity.  In 
addition,  schematic  diagrams  are  prepared  using  this  system  and  graphics  are 
transferred  from  the  SCI-CARDS  system  for  formatting  on  the  final  drawing. 

o  COMPUTERIZED  TEXT  PROCESSING  SYSTEMS  are  used  in  the  preparation  of 
A-size  text  drawings  such  as  Test  Requirement  Documents,  Systems  Specifications, 
etc. 

o  CHANGE  HANDLING  AND  STATUSING  INFORMATION  SYSTEM  (CHASIS)  was 
designed  to  aid  the  Contracts  Division  in  the  preparation  of  formal  changes 
requiring  government  approval  and  contract  modifications.  It  is  an  IMS  data  base 
system  that  provides  all  the  standardized  documents  required  to  complete  an 
Engineering  Change  Proposal  (ECP)  in  an  on-line  environment.  As  soon  as  the  ECP  is 
loaded  on  the  data  base,  it  is  available  throughout  the  division  for  ir.  pact  and  to  the 
government  for  review.  This  system  provides  all  of  the  text  and  forms  required  to 
submit  an  ECP.  Approval  of  the  ECP  is  by  a  password  controlled  system  accessible 
by  terminals  in  the  project  manager's  office. 

An  interfacing  data  delivery  system  was  developed  that  extracts  data  from  these  various 
data  bases  and  combines  it  into  a  neutral  data  base  and  makes  it  available  to  the  user  on 
demand.  The  original  objectives  of  this  integrated  system  were: 

(1)  Develop  an  interface  program  that  allows  data  from  the  several  engineering 
and  configuration  management  software  systems  used  at  Martin  Marietta 
Orlando  Aerospace  to  flow  into  a  common  format. 

(2)  Develop  a  program  that  permits  the  user  to  select  documents  in  the 
engineering  data  base  for  transmission  to  his  terminal. 

(3)  Provide  the  user  with  direct  viewing  of  engineering  drawings  and  changes, 
thereby  supplementing  the  capability  to  examine  engineering  configuration  and 
status  data  contained  in  DIACS. 

(4)  Develop  an  interface  program  to  convert  in-house  data  into  a  format  that  is 
acceptable  to  the  government  for  submittal  as  Technical  Data  Packages 
(TDPs). 

(3)  Develop  techniques  which  integrate  manually  prepared  drawings  and  test  data 
into  the  system. 

The  system  has  been  operational  since  early  1982  and  is  called  the  Martin  Marietta 
Aerospace  Integrated  Data  Systems  (MM  AIDS). 

Before  selecting  a  common  data  base  format  for  MMAIDS,  we  measured  the  volume  of 
data  the  system  would  handle  and  studied  several  possible  common  formats.  A  CADAM 
formatted  data  base  was  selected  for  in-house  and  direct  government  access.  Several 
factors  influenced  this  decision:  1)  CADAM  is  by  far  the  major  computer  graphics  system 
used  in-house;  2)  SCI-CARDS  does  not  produce  a  completely  formatted  finished  drawing; 
and  3)  there  was  a  readily  available  hardware/software  package  (SOFTCOPY)*  for  direct 
access  to  the  CADAM  type  data  base.  To  enhance  the  flexibility  of  MMAIDS,  an  Initial 

♦COMPUTERVISION  CORPORATION  is  located  in  Bedford,  Massachusetts 
♦♦SOFTCOPY  is  an  IBM  product. 
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Graphics  Exchange  Specification  (ICES)  format  for  the  delivery  of  TDP  documentation 
was  also  selected. 

As  shown  in  Figure  1.  all  Pershing  project  documents  prepared  using  Text  Processing  (T) 
equipment  are  transferred  via  an  IBM  3270  interface  (2)  to  the  IBM  3033  and  run  through 
a  CADAM  conversion  program  (3)  with  the  resulting  output  stored  on  an  intermediate 
data  base  (A).  Drawings  prepared  on  CADAM,  Appoilo  or  Applicon  (4)  are  copied  directly 
on  the  intermediate  data  base  (A).  The  artwork  created  by  the  SCI-CARDS  system  (5)  is 
transferred  to  COMPUTERVTSION  (7).  Using  the  COMPUTERV1SION  system,  designers 
place  the  artwork  on  a  format  and  add  other  notations  required  to  complete  the  drawing. 
Drawings  generated  on  COMPUTERVISION  (7)  are  converted  to  CADAM  format  (8)  and 
stored  on  the  intermediate  data  base  (A).  All  data  stored  on  the  intermediate  data  base 
is  statused  as  "read  only".  Non-computer-generated  documents  (9),  comprised  primarily 
of  data  submitted  by  sub- contractors,  will  be  automatically  digitized  (10),  processed 
through  a  CADAM  conversion  program  (11),  and  stored  on  the  intermediate  data  base 

(A) .  Presently,  this  segment  of  the  system  is  an  open  item.  We  have  not  been  able  to 
locate  automated  scanning  equipment  that  digitizes  data  with  the  accuracy  we  believe  is 
required.  However,  the  "Audre"  system  was  reviewed  last  month  and  appears  to  be 
adequate. 

As  the  completed  engineering  drawing  are  approved  and  processed  through  the  normal 
release  system  (12),  DIACS  (13),  which  is  updated  from  a  reserved  to  released  status,  will 
cause  an  IMS  subroutine  to  create  a  Time  Sharing  Option  (TSO)  data  set  for  execution  of 
the  Document  Transfer  Program  (14)  that  moves  the  digitized  information  from  the 
Intermediate  Data  Base  (A)  to  the  Program  Document  Data  Base  (B).  If  the  document 
cannot  be  found  at  the  proper  revision  level,  an  error  report  is  generated. 

From  the  moment  the  first  document  is  transferred  to  the  Program  Document  Data  Base 

(B) ,  the  Pershing  Configuration  Management  Office  (15)  has  on-line  access  to  view  or 
print  a  reduced  electrostatic  copy  using  the  SOFTCOPY  package  116). 

The  SOFTCOPY  capability  is  a  critical  element  in  speeding  up  approval  of  ECPs.  With 
CHASIS  (17),  we  have  had  our  ECP  text  data  on-line  in  the  IMS  environment  to  permit 
full  interchange  of  data  between  the  government  and  contractor.  With  SOFTCOPY  (16), 
the  Configuration  Management  Office  can  receive  changes  of  any  engineering  drawing 
that  is  part  of  the  ECP.  By  interleaving  the  graphics  and  text,  the  configuration  manager 
has  everything  he  needs  to  approve  or  reject  an  ECP.  If,  on  the  other  hand,  more  data 
are  required  before  making  this  decision,  the  system  will  provide  it  upon  request. 
CHASIS  has  a  built-in  subroutine  to  approve  ECP's  under  complete  control  of  the 
Configuration  Management  Office.  When  the  government  (15)  needs  an  entire  TDP,  the 
capability  exists  to  access  DIACS  03)  to  request  a  printout  (19)  of  the  documents  which 
define  the  baseline  of  the  end  item  or  to  request  the  listing  as  well  as  an  IGES  formatted 
tape.  If  a  tape  is  requested,  DIACS  transfers  the  identification  of  the  documents 
comprising  the  TDP  (20)  to  a  TSO  data  set  which  executes  a  program  for  accessing  the 
Program  Document  CADAM  formatted  data  base  (R).  The  program  selects  the 
documents,  processes  them  through  a  CADAM-to-IGES  Conversion  Program  (21),  and 
builds  a  TDP  Tape  (22)  for  delivery. 

The  concept  of  a  computerized  system  for  the  delivery  of  technical  design  and 
configuration  management  data  has  been  presented.  This  sytem  gives  easy,  real  time, 
paperless  access  to  the  specific  data  required  by  the  user  and  accomplishes  the 
following: 


(1)  Real  time  access  to  the  data  base  always  provides  current  data. 

(2)  The  user  can  examine  the  available  data  and  order  what  is  specifically  needed. 

(3)  The  time  to  process  a  change  for  approval  and  distribute  approved  changes  is 
markedly  reduced. 

(4)  Delivery  of  a  partial  or  complete  TDP  can  now  be  accomplished  faster  and 
with  greater  accuracy. 
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USING  THE  XEROX  STAR 


Charles  D.  Fisher 

RCA  Government  Communications  Systems 
Camden,  New  Jersey 

INTRODUCTION:  RCA,  like  most  other  companies,  is  seeking  ways  in  which  to 
increase  engineering  office  productivity.  Word  processors  are  widely  used,  with 
their  use  increasing  every  day.  One  of  the  devices  being  evaluated  within  RCA  is 
the  XEROX  "STAR"  or  8010  workstation.  This  paper  is  based  on  our  experience 
with  STAR  in  a  data/configuration/publications  management  environment.  We 
prepared  this  paper  -  including  all  graphics  --  on  a  STAR  workstation. 


WHY  THE  XEROX  STAR???  WHAT  DO  WE  HAVE??? 


Before  STAR  was  announced,  we 
had  acquired  a  number  of  Xerox  860 
workstations  for  our  engineering 
document  composition  system.  This 
system  consists  of  standalone 
workstations  linked  to  a  central  file 
and  printing  facility,  permitting 
resources  to  be  shared  while  at  the 
same  time  allowing  independent 
standalone  operation. 

STAR  offered  us  added  capabilities 
-  including  graphics  and  special 
equations  -  compatible  with  what  we 
already  had.  We  wanted  to  add  to, 
rather  than  alter,  what  we  had  so  that 
the  skills  already  acquired  by  our 
professional,  technical,  and  clerical 
staff  would  not  be  lost.  We  needed 
only  to  supplement  their 
existing  skills. 

Our  purpose  today  is  to  briefly 
describe  our  experience,  hoping  that 
you'll  find  it  of  interest.  The  STAR  is 
not  the  answer  to  everyone's  needs, 
and  this  paper  should  not  be  regarded 
as  an  endorsement  of  any  product  by 
RCA,  ADPA,  or  myself. 


The  system  environment  in  which 
we  use  the  STAR  is  shown  in  Figure  1 . 
In  addition  to  STAR,  860  workstations 
are  used  for  input  --  for  straight  text 
and  tabular  word  processing  we'll  use 
the  860  in  preference  to  STAR. 

We  have  two  laser  printers.  The 
Xerox  5700  laser  printer  is  used  where 
we  need  higher-speed  reproduction; 
it  isn't  always  possible  to  use  the  5700 
--  it  doesn't  have  the  font  range  or 
graphics  handling  power  of  the  Xerox 
8044  {the  slower-speed  laser  printer). 
The  5700  accepts  diskettes  from  the 
860  workstations,  from  the  OCR 
scanner,  or  from  IBM  workstations. 

We  also  have  impact  printers,  most 
with  paper  feeders.  At  our  central 
location  we  also  have  a  wide-carriage 
printer,  for  copy  up  to  about  25  inches 
wide. 

The  file  server  provides  storage  for 
data  and  support  (training,  help)  soft¬ 
ware. 

We  also  have  an  off-line  OCR  read¬ 
er,  producing  diskettes  for  the  860. 
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Figure  1.  The  System 
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DO  WE  NEED  ALL  THIS??? 

The  STAR  is  part  of  a  larger  system. 

It  is  only  one  workstation  on  that  system, 
sharing  resources  with  all  the  other  work¬ 
stations.  For  our  purposes,  all  we  need  is 
the  group  of  items  shown  at  the  right. 

We  created  this  figure  by  copying  it  from 
figure  1  and  enlarging  it.  The  small  figure 
(upper  corner)  is  a  reduced  copy. 

DISPLAY  (10x13  SCREEN) 


KEYBOARD  AND  "MOUSE" 


(LEFT)  PROCESSOR 


(RIGHT)  DISKDRIVE 

(We  do  need  the  file  and  laser  printer  for 
output,  but  this  document  was  created  at 
the  workstation  keyboard  without  use  of 
the  other  equipment.  We  also  need  the 
ETHERNET  (coax  cable)  link  between  the 
units.) 


Figure  2.  STAR  Workstation 


ONE  USE  FOR  STAR'S  GRAPHICS  CAPABILITY  IS  ILLUSTRATED  BELOW.. 

Gantt  charts  are  widely  used  for  milestone  schedules  in  data,  configuration,  and 
publications  management  plans  as  well  as  other  program  documents. 
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ANOTHER  FREQUENT  USE  IS  THE  PREPARATION  OF  SLIDES... Such  as  the 
two  shown  below.  OTHER  STAR  PRODUCT  EXAMPLES  appear  at  the  end  of 
this  paper.  These  examples  include  both  some  we  prepared  and  some  applications 
examples  obtained  from  XEROX. 


available  functions 

document  creation,editing,and  printing 

OPERATION  SUMMARY 

mailing  and  filing 

LOG  ON. ..NAME  AND  PASSWORD 

graphics 

RECALL  DESKTOP 

records  processing 

CREATE/MODIFY  DOCUMENT 

forms 

PRINT,FILE,MAIL  DOCUMENTS 

equations 

emulations 

LOG  OFF,  STORE/CLEAR  DESKTOP 

Figure  4.  "Functions"  Slide  Figure  5.  "Operations"  Slide 


LEARNING  TO  USE  THE  STAR . 

XEROX  does  not  normally  conduct 
formal  training  classes  for  STAR  oper¬ 
ators...  there  are  so  many  possible 
applications  that  they'd  be  hard- 
pressed  to  give  generalized  training. 
Some  STAR  training  is  given  as  a  part 
of  the  formal  "system  administrator" 
training  for  ETHERNET.  Most  user 
training  is  done  by  the  operators 
themselves,  using  the  STAR  software 
and  learning  attneirown  pace. 

An  "INTRODUCTION"  offered  at 
loq-on  time  allows  the  first-time  {or 
infrequent)  user  to  get  started.  There 
are  three  reference  books: "  Learner's 
Guide",  "Quick  Reference  Guide",  and 
a  complete  "Reference  Guide"  but  for 
the  most  part  the  "trainee"  will  be 
looking  at  the  display.  Training  seg¬ 
ments  can  be  selected  to  suit  needs. 
Users  can  start  and  stop  where  they 
wish.  Each  segment  includes  examples 
and  exercises,  a  few  give  "quizzes." 


. HOW  LONG  DID  IT  TAKE??? 

When  someones  asks  me  how  long 
I  spent  learning  to  use  the  STAR, 

I  must  confess  that  I'm  still  learning. 
(Any  STAR  user  in  this  audience  could 
teach  me  something.)  To  run  through 
all  of  the  training  segments,  doing  all 
of  the  exercises,  and  taking  each  quiz 
will  take  at  least  a  week.  Hands-on 
experience  with  another  system  may 
lessen  the  time  needed. 

OPERATIONAL  SEQUENCE 

Let's  assume  that  you’ve  gone 
through  all  of  the  on-line  training  seg¬ 
ments  and  know  what  you  want  to  do. 
The  following  is  a  summary  of  what 
you'd  do  to  prepare  a  document  such 
as  this  paper. 

FIRST, you  log-on.  This  is  simply  a 
matter  of:  pressing  any  key  on  the 
keyboard,  typing  your  name,  and 
typing  your  password. 
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OPERATIONAL  SEQU  ENC E(contd) 

SECOND,  your  "desktop"  will 
appear  on  the  screen.  What  you 
actually  see  are  small  picture-like 
objects  called  "icons"  shaped  to 
resemble  file  folders,  in-  and  out- 
baskets,  your  printer,  and  the 
"directory"  from  which  you  access 
existing  files,  blank  documents  or 
folders,or  transfer  documents. 

THIRD,  you  select  and  "open"  the 
file  and/  or  document  on  which 
you're  going  to  work.  To  do  this, 
you  manipulate  a  small  device 
called  a  "mouse"  on  which  there 
are  two  buttons.  Moving  the 
mouse  over  a  hard  surface  causes 
an  arrow-shaped  cursor  to  move 
around  the  screen.  Selections  are 
made  by  clicking  the  buttons  on 
the  mouse.  When  a  selection  has 
been  made,  the  arrow  changes 
shape  (hourglass)  while  the  STAR  is 
executing  your  commands. 

FOURTH,  when  the  STAR  hasdone 
what  you  wanted  (e.g., "opened"  — 
displayed  in  a  "window"  on  your 
screen  -  the  document  you're 
working  on)  the  arrow  reappears. 
You  can  now  -  using  the  keyboard 
and  mouse  -  do  any  or  all  of  the 
following  things: 

(1)  Create  a  new  document 

(2)  Edit  an  existing  document 

(3)  Duplicate  or  move  copy 

between  documents 

There's  no  need  to  create  a 
new  document  every  time. 
Existing  forms  can  be  copied 
and  altered.  Figures  and  text 
can  be  lifted  from  one  doc¬ 
ument  and  placed  in  another. 
Graphics  can  be  copied  from  on¬ 
line  "transfer"  sheets. 


(4)  Change  properties ,e.q 

•  Change  type 

•  Font  •  Weight 

•  Shape  •  Spacing 

•  Change  line  or  border 

•  Structure 

•  Weight 

•  Change  graphics  object 

•Size  •  Texture 

•  Shape  •  Shading 

FIFTH,  you  can,  either  or  both, 
print/file  the  document  you've 
just  worked  on 

THEN....  you  can  select  another 

document  to  be  worked  on . 

OR  log  off  until  you  need  the 
STAR  again. 

STAR  CAN  ALSO  BE  USED  FOR 


RECORDS  PROCESSING... 

Including  calculations, 
sorting,  logical  choices, 
forms  fill-in  etc.,  BUT 
setup  is  time-consuming 

TERMINAL  EMULATION... 

IBM  3270  series 
TTY 

ELECTRONIC  MAIL... 


DATA-DRIVEN  GRAPHICS... 
Bar  Charts 


USING  THE  XEROX  STAR 


I 


THE  STAR  KEYBOARD 

The  keyboard  is  essentially  that  of 
a  typical  QWERTYtypewriter  except 
for  a  few  keys  (<>{}[]).  Th  ree 
groups  of  function  keys  are  added. 
One  row  (top  group)  is  above  the 
character  keys  and  two  are  at  either 
side  (right  and  left  groups). 

The  use  of  the  character  keys 
and  the  top  function  group  will  be 
changed  temporarily  when  certain 
functions  are  selected.  The  temp¬ 
orary  functions  will  be  displayed  on 
the  screen  (virtual  keyboards).  This  is 
done  when  entering  foreign  language 
characters,  office/logic/  math  symbols, 
and  "frames"  for  the  insertion  of 
graphics  and  special  equations.  The 
top  group  of  function  keys  can  be 
used  either  to  perform  some  of  the 
graphics  functions  or  to  change  fonts. 


THE  STAR  DISPLAY 

The  display  is  a  10-  by  13-inch 
screen  on  which  text  and  graphics 
objects  appear  at  almost  their  final 
(printed)  size,  and  shape.  The  screen 
has  less  resolution  than  the  printed 
page,  but  otherwise  what  you  see  is 
almost  what  you  get.  The  icons,  about 
one  inch  square,  can  be  positioned 
where  the  operator  wishes.  Open 
documents  appear  in  windows. 

When  more  than  one  document  is 
open,  the  windows  are  made  smaller 
and  the  user  sees  less  at  one  time.  Up 
to  six  windows  can  be  open  at  any 
time.  Properties  frames  also  appear  in 
windows,  but  only  while  being  used. 

Figure  6  will  give  you  some  idea  of 
what  it  looks  like.  HELP  only  appears 
when  called  for. 


USING  THE  XEROX  STAR 


CLOSING  COMMENTS... 

We  do  not  intend  to  suggest  that  any  or  all  of  you  run  out  and  buy  or  rent  a  STAR. 

Our  experience  thus  far  has  been,  for  the  most  part,  positive  BUT  the  final  ver¬ 
dict  isn't  in.  Forthcoming  software  enhancements  are  expected  to  clear  up  most  of 
the  limitations  we've  encountered.  XEROX  appears  to  be  committed  to  this  product 
and  they  should  have  the  resources  to  support  it  in  whatever  way  is  needed. 

In  the  table  above  and  the  attached  examples  we've  tried  to  cover  the  more 
likely  applications  as  we  see  them.  There  are  probably  many  more  than  we  can 
imagine.  If  you  have  any  questions.  I'll  try  to  answer  them. 


USING  THE  XEROX  STAR 


THE  ATTACHED  EXAMPLES: 

PART  DRAWING  -  Line  drawing  for  small,  simple  part 

OBJECTS,etc.,-  Prepared  as  large  transparency,  shows  basic 
graphic  objects,  lines,  shading,  texture.  "Grid 
Properties  "  are  visible  on  display  but  do  not  print. 

OFFICE  AUTOMATION  -  Shows  use  of  shading,  line  work,  and 
text  entry 

USA  MAP  -  Done  by  tracing  on  the  display. 

BEAKER  GRAPH  -  Uses  different  shapes  and  shadings  to  obtain 
rendered-drawing  effect 

BAR  GRAPH  -  Example  of  data-driven  graphics.  Operator 
enters  values  and  captions,  selects  shading  and 
orientation,  STAR  plots  and  places  graphics.  Chart  can 
be  re-oriented  (e.g, horizontal  to  vertical)  until  de¬ 
sired  presentation  is  obtained. 

SPECIAL  EQUATIONS  -  Requires  insertion,  from  keyboard,  of 
equation  frames.  STAR  automatically  positions 
cursor  at  argument  fields. 


OBJECTS,  LINES, 

SHADINGJEXTURE  Line  Line  Line  Ends:  Line  Ends: 

(CAN  BE  TRANSFERRED  OR  COPIED )  Width  Structure  Left  (Upper)  Right 


(GRID  MARKS  APPEAR  ON  DISPLAY) 


SAMPLE  EQUATIONS 


The  basic  problem  is  described  by  a  transient  one-dimensional  diffusion  model: 


where  C(x,0)  =  C0 

C  (x,t)  =  0 
dc 

(o,o  =  o 

dx 

The  exact  solution  to  this  equation  is: 

00 

dx,t)  =  ^  M  exp(  —  DX2t)cosX  x 

n  n  n 

where 

/  2  sinX  L 

M  =  C  ( - 2 - 

n  0  \  X  L  +  sinX  LcosX  L 

n  n  n 

The  average  concentration  is  given  as: 

■  L 


(1) 


(2) 


) 


If 

C  =  -  C(x,t)dx  =  y  (LX  )~lM  exp  (-DX  2t)sinX  L 

avS  L  J  n  n  n  n  n 

u  n  =  1 


(3) 


Since  tables  for  concentration  as  a  function  of  time  for  various  values  of  x/L  have  been  constructed, 
consider  the  ratio  of  Cavg  to  C(0,t),  the  centerline  value. 


C  ®  XL 

a vg  n 

-  =  >  sin  - 

fZx  KL 


(4) 


but  it  can  be  shown  that: 

A  L  tanX  /  =  0  (5) 

n  n 

We  can  then  show,  by  substituting  the  roots  of  the  transcendental  equation  5  into  equation  4  that: 
C  /  C  (0,0  =  0.533  (6) 

avg 
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COPIES 


TO 

E.  SHROLU 

DATE 

JAN  27.1984 

1  DATA  ALERT  i 

Subject 

Program/Contract 

(CODE) 

ALBATROSS/N789S6 

(ALB) 

CDRl 

Seq  No 

A013B 

Data  Item 
Name 

CONFIGURATION  MANAGEMENT  PLAN 

Your  activity  has  been  assigned  primary  responsibility  for  supplying  the  contract  data  item  identified  above 


Delivery 

of 

ROUGH  DRAFT 

to  Data  Management  (see  name  below)  is 
required  not  later  than  Noon  on 

FEB  13.1984 

Applicable  (DID  DD  Form  1664) 
Data  Item  Description  is 

DI-E-2035A 

Data  Item 
Description 

IS  NOT 

Modified  by  CDRL 

Transmittal  to  customer  is  scheduled 
for  not  later  than: 


FEB  28.1984 


Customer  comments  are 
expected  on  or  before 


APRIL  1,1984 


Additional: 

comments: 


SEE  SOW  3.6.3.2  (a)  AND  PROPOSAL  VOLUME  3  PARA  4.2.— 
APPLICABLE  TO  HARDWARE  .SOFTWARE, AND  INTERFACE  CONTROL 
WORKING  GROUP  PARTICIPATION. 


Please  advise  immediately  if  added  information  is  needed  or  if  problem  is  anticipated  in  meeting  the 
required  submittal  dates 


FROM 


A.  J.  ZILCH/13-3/3241 

Name/Location/Extension 

|  DATA  ALERT 

I.A.PHINOUE 

i 

K.K.ROSS 

Engineering  PMO 

D.R.SCHULTZ 

L.  McDEVITT 

Editing/Quality  Other 


PROTECTION  AND  CONTROL 

•  BACKUP  ON  DISKETTES  • 

•  MASTER  COPY  IN  CONTROLLED  "LIBRARY" 

•  "PRINT-FORMAT"  DOCUMENTS 
DELIVERED,  DISTRIBUTED,  ACCESSIBLE 
ON-LINE 

•  USE  "TIME-DATE"  FEATURE  WITH  OTHER 
IDENTIFICATION 
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INTRODUCTION 


In  addressing  the  status  of  any  activities  associated  with  proposed  changes 
to  MIL-STD-885B ,  Procurement  Data  Packages,  I  would  beg  your  indulgence  for 
a  brief  overview  of  the  need  for  Procurement,  Acquisition  or  the  more  familiar 
Reprocurement  Data.  I'd  like  to  extend  credit  to  Mr.  Chuck  Feely  as  the 
source  for  some  of  the  background  I'll  be  discussing.  He  said  it  so  well  in 
his  Data  Management  Course  at  AFIT,  I  could  not  improve  on  it. 

I  would  like  to  quote  a  sentence  from  U.S.  Code  10,  2304: 

"The  Secretary  of  Defense  is  hereby  directed  that  insofar  as  practical,  all 
contracts  shall  be  formally  advertised  and  awarded  on  a  competitive  bid 
basis  to  the  lowest  responsible  bidder." 

This  quotation  does  not  allow  for  much  wandering  from  its  principle  intent, 
does  it?  The  only  caveat  is  "insofar  as  practical,"  and  to  date  there  is 
no  universal  interpretation  of  exactly  how  far  we  in  the  DOD  have  to  go 
before  we  deem  a  procurement  can  and  should  be  competitive  rather  than  being 
awarded  sole-source.  From  a  data  managers  viewpoint,  however,  the  caveat 
really  states  "whenever  an  appropriate  data  package  exists".  In  a  nut  shell, 
a  good  data  package  is  the  whole  secret  behind  an  effective  reprocurement. 

THE  HEART  OF  COMPETITIVE  PROCUREMENT  IS  DATA. 

BACKGROUND 


Let's  put  things  into  some  sort  of  perspective.  When  we  in  DOD  procure  and 
field  systems  and  equipment  such  as  aircraft,  ships,  tanks,  missiles  and  the 
thousands  of  other  items,  it  is  done  with  the  full  realization  that  there 
are  subparts  that  will  wearout  or  fail  under  operation,  be  broken  or  damaged 
during  shipping  and  handling  and  need  to  be  replaced,  in  order  to  return  the 
system  or  end  item  to  a  serviceable  or  useable  state.  These  subparts  will 
be  procured  many  times  over  during  the  life  of  the  system  or  end  item  thus 
the  term  Reprocurement  was  coined  to  indicate  a  buy  subsequent  to  the  buy 
or  the  initial  provider  (source).  Remember,  the  first  supplier  of  the  sys¬ 
tem  or  end  item  satisfies  the  DOD's  requirements  through  someones  part  num¬ 
ber,  either  his  own  or  some  other  manufacturers  or  source  of  supply.  DOD 
by  virtue  of  U.S.  Code  10  and  good  business  sense,  does  not  want  to  be 
limited  to  just  one  part  number  or  source  because  of  many  reasons  such  as  the 
company  going  out  of  business,  deciding  against  future  involvement  with  a 
particular  part  nurbor,  crrosion  of  quality,  price-jabbing,  and  many  others. 

We  in  DOD  would  like  to  have  multiple  sources  of  supply  for  every  subpart  we 
need  to  buy,  whereas  many  companies  want  to  be  the  sole-source  or  only  supplier 
because  they  believe  that  future  profits  can  be  assured  since  they  know  and 
can  predict  wear  out  and  replacement  quantities  hence  guaranteed  business. 

The  DOD  must  compensate  an  initial  provider  of  the  major  item  for  identifying 
which  parts  and  subparts  can  be  bought  on  a  separate  basis  and  in  accordance 
with  the  quantities  estimated.  This  identification  requires  information  or 
data  to  completely  define  the  physical  and  functional  attributes  of  the  sub¬ 
part,  its  manufacturing  techniques  plus  all  other  data  that  will  permit  the 
subpart  to  be  provided  by  any  competent  source  in  the  same  physical  or  func¬ 
tional  characteristics  as  that  made  by  the  original  source.  These  concept- 
are  the  basis  for  what  we  in  the  acquisition  business,  both  government  and 
industry  call  "item  breakout".  The  basic  steps  to  accomplish  item  breakout 
are : 
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1.  DOD  satisfaction  with  the  initial  system  or  end  item  (aircraft, 
ship,  etc.)  and  its  subparts  that  make  up  that  system  or  end  item. 

2.  Identification  of  these  subparts  that  will  be  needed  as  spare  and 
repair  parts  during  the  life  of  the  system  or  end  item. 

3.  Ability  to  obtain  comprehensive,  accurate,  and  descriptive  informa¬ 
tion  on  the  subparts  identified  as  spare  and  repair  parts.  These  data  must 
include  material  specifications,  manufacturing  processes,  testing,  lists  of 
many  kinds,  and  packaging,  handling,  preservation  and  transportation  variables. 

4.  The  capability  of  another  manufacturer  to  provide  ostensibly  the  same 
functional  and  physical  interchangeable  or  identical  subpart.  We  must  remem¬ 
ber  that  in  addition  to  reaping  any  monetary  savings  through  item  break-out 
and  competition  reprocurement,  we  must  insure  second  or  alternate  sources  for 
all  spare  and  repair  parts  to  maintain  system  support  and  readiness. 

DOD  Acquisition  Improvement  Program  (AIP)  initiative  six  directs  all  acqui¬ 
sition  management  activities  to  establish  appropriate  program  objectives  to 
enhance  competition  for  our  supplies  and  services.  As  stated  earlier,  the 
heart  or  foundation  of  any  procurement  action,  including  reprocurement  is  the 
combination  of  data  and  information  necessary  to  describe  an  item  so  that 
either  an  identical  or  interchangeable  item  can  be  procured. 

Since  1979,  the  Air  Force  has  been  investigating  the  causes  for  sharp  increases 
in  prices  paid  for  certain  spare  and  repair  parts.  The  investigation  high¬ 
lighted  that  for  various  reasons,  the  Air  Force  does  not  and  could  not  take 
maximum  advantage  of  competition  market  forces  in  executing  its  spares  acqui¬ 
sition  programs.  These  investigations  coupled  with  recent  congressional 
pressures  led  to  the  chartering  of  the  Air  Force  Management  Advisory  Group 
(AFMAG ) .  The  AFMAG  was  a  study  conducted  last  fall  of  the  Air  Force  Acquisition 
process.  The  study  highlighted  the  need  for  development  of  methods  to  ensure 
fair  ana  reasonable  prices  and  increased  competition  for  spare  and  repair  parts. 

AFMAG  ACTIVITIES 

The  study  found  that  the  process  of  defining  contract  requirements  for  procure¬ 
ment  data  packages  is  complex  and  unwieldy,  often  resulting  in  incomplete  and 
unuseable  data.  This  limits  the  DOD's  ability  to  competitively  procure  spare 
and  repair  parts.  One  of  the  key  factors  causing  this  problem  has  been  the 
ambigeous  methods  of  describing  and  delivering  what  constitutes  an  adequate 
procurement  data  package . 

Over  the  past  10-12  years,  there  has  been  a  constant  change  in  the  methods  and 
techniques  used  to  define  engineering  data  requirements  in  directives,  regula¬ 
tions,  and  other  policy  documentation.  Prior  to  1975,  the  primary  description 
of  engineering  data  was  contained  in  MIL-D-1000,  Engineering  Drawings  and 
Associated  Lists.  This  document  established  requirements  for  drawings  in 
terms  of  categories  of  use  (content)  and  form  (format).  Description  of  data 
was  provided  by  individual  data  item  descriptions  for  each  of  ten  separate 
categories  of  use.  In  1971,  the  Air  Force,  in  an  attempt  to  streamline  this 
process  prepared  MIL-STD-885,  that  would  call  out  a  procurement  data  list,  and 
an  attendant  DID  (DI-E-3472,  Procurement  Data  Packages)  that  provided  the 
data  including  all  engineering  data. 

In  1975,  a  major  change  was  made  to  MIL-D-1000  to  clarify  and  simplify  the 
description  of  engineering  drawings.  MIL-D-1000A,  described  drawing  content 
in  terms  of  levels  of  program  development.  It  describes  the  development  of 


an  engineering  drawing  system  as  an  evolutionary  process  progressing  in  greater 
detail  through  the  concept  (Level  1),  prototype  production  (Level  2),  and  pro¬ 
duction  phases  (Level  3)  of  a  system  or  equipment  development.  Further, 
instead  of  ten  separate  data  item  descriptions  under  the  pre-1975  system,  one 
data  item  description  would  be  used  to  obtain  drawings.  As  a  result  of  these 
changes  and  the  subsequent  revision  to  MIL-D-1Q00  and  M1L-STD-100,  it  became 
apparent  to  the  AFMAG  that  MIL-STD-885  had  not  kept  pace  with  changes  to 
these  specifications,  standards  and  their  associated  data  item  descriptions. 

The  AFMAG  recommended  that  MIL-STD-885  be  updated  and  revised  to  correlate 
it  with  existing  and  proposed  changes  to  engineering  data  policy,  and  pro¬ 
vide  updated  guidance  for  the  content  and  delivery  of  procurement  data 
packages . 

As  the  Preparing  Activity  and  Air  Force  custodian  lor  MII.-STD-885,  I  called 
a  meeting  of  joint  service  and  industry  representatives  in  March  to  charter 
a  work  group  and  establish  the  ground  rules  and  schedules  for  revising  MIL- 
STD-885. 

PLANNING  MEETING 

After  a  brief  review  of  DOD,  and  service  directives,  specifications,  and 
standards  relating  to  engineering  and  procurement  data,  the  meeting  was  placed 
on  open  floor  discussion  on  engineering  drawings,  engineering  data,  and  the 
data  necessary  to  permit  competitive  procurement  of  an  item.  After  much 
discussion,  it  became  apparent  that  there  are  varied  interpretations  of  what 
engineering  drawings,  engineering  data,  and  procurement  data  are.  It  was 
also  apparent  that  there  are  different  methods  for  obtaining  procurement  data 
lists  and  packages. 

Ted  Golmis ,  representing  industry  through  ADPA,  advised  the  group  that  industry 
in  general  believes  drawings  prepared  to  Level  3  provide  all  information 
required  to  manufacture  an  item  for  production.  He  also  pointed  out  that  other 
data  such  as  corrosion  control,  some  acceptance  test  and  packaging,  handling, 
and  transportation  data  is  not  delivered  as  engineering  data  but  is  required 
for  competitive  procurement. 

A  concensus  was  reached  that  in  addition  to  Level  3  drawings,  procurement 
data  lists,  and  other  procurement  data  are  also  needed  for  competitive  pro¬ 
curement  of  spare  and  repair  parts.  Mr.  Golmis  stressed  the  fact  that  the 
government  is  already  privy  to  all  engineering  data  and  drawings,  but  that 
out  biggest  problem  was  communication.  We  need  to  zero  in  on  what  it  is  we 
really  want,  what  do  we  think  we  are  asking  for,  and  how  do  we  want  to  docu¬ 
ment  and  deliver  this  information. 

SUMMARY 

Based  on  what  I  just  finished  saying,  it  is  apparent  that  a  strong  need  exists 
for  a  document  such  as  MIL-STD-885.  To  that  end,  I  have  started  on  a  draft 
revision  to  the  MIL-STD  and  its  data  item  description.  Recognizing  the  prob¬ 
lems  involved  in  coordinating  a  document  through  the  Air  Force,  and  the  even 
tougher  hoops  in  a  joint  service  and  industry  effort,  I  am  confident  and 
optomistic  that  we  can  have  a  coordinated  document  ready  for  publication  by 
next  year. 


I  am  also  asking  Che  Defense  Materiel  Sp>  cification  and  Standards  Office 
(DMSSO)  to  initiate  a  project  to  evaluate  the  various  methods  and  documents 
used  by  the  services  for  obtaining  procurement  ciata  lists  and  packages,  and 
recommend  a  single  standard  or  uniform  method  to  be  used  by  all  DOD  compon¬ 
ents.  To  pull  all  of  this  together  I  soLicit  your  strong  support  and  active 
involvement  in  reviewing  and  commenting  on  the  proposed  draft  scheduled  for 
release  in  late  July. 


TECHNICAL  DOCUMENTATION 


AS  RELATED  TO 


COMPETITION 


Captain  Thomas  J.  Burke,  USN 

Commanding  Officer,  Naval  Sea  Systems 
Command  Logistics  Support 
Engineering  Activity 

Officer  in  Charge,  Naval  Electronic 
Systems  Command  Detachment 
Mechanicsburg 

Engineering/Technical  Assistant  to 
Commanding  Officer,  SpCC 
P.  0,  Box  2020 
Mechanicsburg,  PA  17055 
717-690-2711 


GOOD  HORNING  LADIES  AND  GENTLEMEN.  IT  IS  A  DISTINCT  PLEASURE 


FOR  ME  TO  BE  HERE  AT  THE  26TH  ANNUAL  MEETING  OF  THE  TECHNICAL 
DOCUMENTATION  DIVISION  OF  THE  AMERICAN  DEFENSE  PREPAREDNESS 
ASSOCIATION,  AND  TO  REPRESENT  THE  U.S.  NAVY.  I  MUST  ADD  THAT 
I  ALSO  REPRESENT  THE  CENTRAL  PENNSYLVANIA  MANAGEMENT  CHAPTER 
OF  ADPA  LOCATED  IN  MECHANICSBURG,  PENNSYLVANIA,  WHERE  I  AM  A 
MEMBER  IN  GOOD  STANDING,  AND  HAVE  BEEN  NOMINATED  FOR  THE 
CHAPTER  PRESIDENCY  FOR  OUR  ELECTION  IN  JUNE. 

SOME  OF  YOU  MAY  RECALL  THAT  I  SPOKE  TO  THIS  ASSEMBLAGE 
LAST  YEAR  AT  FORT  MONROE,  VA.  TO  BE  ASKED  BACK  MAKES  ME  FEEL 
ESPECIALLY  GOOD  BECAUSE  SOMETHING  I  SAID  MUST  HAVE  STRUCK 
HOME,  AT  LEAST  TO  SOMEONE.  WHEN  I  WAS  ASKED  TO  SPEAK 

TO  YOU  AGAIN  THIS  YEAR  AND  ASKED  TO  SELECT  A  TOPIC,  I  QUICKLY 
CHOSE  A  SUBJECT  WITH  WHICH  I  HAVE  BECOME  DEEPLY  INVOLVED, 
ESPECIALLY  WITH  REGARD  TO  THE  REPROCUREMENT  OR  REPLENISHMENT 
OF  SPARE  PARTS  FOR  EQUIPMENTS  ON  BOARD  SURFACE  SHIPS  AND 
SUBMARINES.  ONLY  AFTER  I  GAVE  MY  TOPIC  TO  TED  GOLMIS  AND 
REVIEWED  MY  REMARKS  FROM  LAST  YEAR,  DID  I  REALIZE  THE  SIMILARITY 
BETWEEN  MY  LAST  YEAR'S  SUBJECT  AND  MY  CHOICE  FOR  THIS  YEAR. 

•  ■  - jASfflofc. 
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"(TECHNICAL)  DOCUMENTATION  AS  RELATED  TO  COMPETITION/'  IS  A 
FOLLOW-ON  TO  "COMPETITION  AND  COOPERATION."  THUS,  SPEAKING 
TO  YOU  FOR  THE  SECOND  TIME  GIVES  ME  AN  OPPORTUNITY  WHICH  FEW 
SPEAKERS  HAVE— THE  CHANCE  TO  FOLLOW-UP  ON  WHAT  I  SAID  A  YEAR  AGO. 

TO  DO  SO,  I  NEED  TO  REVIEW  SOME  OF  THE  KEY  POINTS  FROM  LAST  YEAR, 
THEN  BRING  YOU  UP  TO  DATE  ON  MY  OBSERVATIONS  AND  PERCEPTIONS  OF  THE 
PAST  YEAR,  AND  FINALLY  MAKE  SOME  SUGGESTIONS  AND  RECOMMENDATIONS 
FOR  THE  FUTURE. 

TO  AGAIN  SET  THE  STAGE  FOR  MY  REMARKS,  AND  SO  THAT  YOU 
WILL  PLACE  THEM  IN  PROPER  PERSPECTIVE,  I  NEED  TO  REFRESH  YOU 
ON  A  FEW  THINGS  ABOUT  MYSELF  AND  THE  ACTIVITIES  I  REPRESENT. 

IT  IS  OBVIOUS  THAT  SOME  OF  MY  REMARKS  WILL  BE  SLANTED  TO  AND 
BIASED  BY  MY  PRESENT  POSITIONS.  FIRST  I  WOULD  REMIND  YOU  THAT 
I  AM  MQI  A  SUPPLY  OFFICER.  I  AM  A  SURFACE  WARFARE  OFFICER — 

A  SHIP  DRIVER.  I  AM  NOT  AN  ENGINEER  BY  EDUCATION;  HOWEVER, 

I  HAVE  A  STRONG  TECHNICAL  BACKGROUND  BOTH  BY  TRAINING  AND 
SHIPBOARD  EXPERIENCE.  I  CURRENTLY  HAVE  ASSIGNMENTS  WITH  THREE 
SEPARATE  ACTIVITIES  IN  THE  MECHANICSBURG,  PENNSYLVANIA,  AREA. 

MY  PRIMARY  DUTY  IS  AS  COMMANDING  OFFICER  OF  THE  NAVSEA  LOGISTICS 
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SUPPORT  ENGINEERN6  ACTIVITY,  A  NAVAL  SEA  SYSTEMS  COMMAND  FIELD 
ACTIVITY.  I  HAVE  AN  ADDITIONAL  DUTY  ASSIGNMENT  AS  OFFICER  IN 
CHARGE,  NAVELEX  DETACHMENT  IN  MECHANICSBURG,  A  NAVAL  ELECTRONICS 
SYSTEMS  COMMAND  FIELD  ACTIVITY.  THESE  ACTIVITIES  ARE  DEEPLY 
INVOLVED  IN  THE  PROVISIONING  PROCESS  FOR  HULL,  MECHANICAL  AND 
ELECTRICAL  EQUIPMENTS,  AS  WELL  AS  SEARCH  RADARS,  SONARS  AND 
TACTICAL  COMPUTERS  FOR  NAVSEA,  AND  FOR  ALL  NAVELEX  EQUIPMENTS. 

IN  ADDITION,  BOTH  ACTIVITIES  PROVIDE  ENGINEERING  SERVICES 
TO  NAVY  SHIPS  PARTS  CONTROL  CENTER  (SPCC)  FOR  RESOLUTION  OF 
TECHNICAL  PROBLEMS  RELATED  TO  SPARE  PARTS  PROCUREMENT. 

WITHIN  THIS  PAST  YEAR,  BOTH  ACTIVITIES  HAVE  BEEN  ASSIGNED 
THE  TASK  OF  REVIEWING  SPARE  PARTS  TECHNICAL  DOCUMENTATION  PACKAGES 
IN  SUPPORT  OF  THE  DEPARTMENT  OF  DEFENSE  "BREAKOUT  PROGRAM"  AS 
IMPLEMENTED  WITHIN  THE  NAVY.  OUR  TASK  IS  TO  DETERMINE  IF  THE 
DOCUMENTATION  AVAILABLE  TO  THE  NAVY  SUPPLY  SYSTEM  IS  ADEQUATE  TO 
PROCURE  SPARE  PARTS  THROUGH  UNRESTRICTED  COMPETITION,  AND  IF  THE 
DOCUMENTATION  INADEQUATE,  TO  OBTAIN  OR  DEVELOP  SUCH  DOCUMENTATION 
WHICH  IS  REQUIRED  TO  MAKE  THE  ITEM  SUITABLE  FOR  COMPETITION  IF  IT 
IS  ECONOMICALLY  VIABLE  TO  DO  SO  -  THAT  IS,  IF  THERE  WILL  BE  A 
NET  SAVINGS  THROUGH  COMPETITION  AFTER  CONSIDERING  THE  COSTS  TO 


OBTAIN  OR  DEVELOP  THE  REQUIRED  DATA,  MORE  ABOUT  THIS  LATER. 

I  LIKE  TO  REFER  TO  MV  PEOPLE,  MOST  OF  WHOM  ARE  ENGINEERS, 

AS  INTERPRETERS  BETWEEN  THE  ACQUISITION  MANAGERS  IN  NAVSEA  AND 
NAVELEX  AND  THE  SUPPLY  SYSTEM,  PRINCIPALLY  SPCC  AS  THE  PRIMARY 
INVENTORY  CONTROL  POINT  FOR  SHIPS.  INTERPRETERS  OBVIOUSLY 
SPEAK  AT  LEAST  TWO  LANGUAGES;  THUS,  MY  ENGINEERS,  IN  ADDITION 

TO  BEING  QUALIFIED  IN  THEIR  OWN  LANGUAGE,  ALSO  SPEAK  "SUPPLY". 

A  LANGUAGE  WHICH  IS  FOREIGN  TO  MOST  OF  THOSE  IN  THE  ACQUISITION 
BUSINESS. 

MY  THIRD  POSITION,  ANOTHER  ADDITIONAL  DUTY  ASSIGNMENT,  IS 
AS  ENGINEERING/TECHNICAL  ASSISTANT  TO  THE  COMMANDING  OFFICER  OF 
SPCC,  COMMODORE  ROBERT  B.  ABELE,  SC,  USN. 

I  WOULD  LIKE  TO  REMIND  YOU  THAT  IN  THE  SHIPS'  WORLD  WE 
HAVE  TWO  GENERAL  CATEGORIES  OF  EQUIPMENTS  -  GOVERNMENT  FURNISHED 
AND  CONTRACTOR  FURNISHED.  MOST  OF  YOU  ARE  MORE  CLOSELY 
ASSOCIATED  WITH  THE  GOVERNMENT  FURNISHED  EQUIPMENTS  WHICH  ARE 
MOST  OFTEN  INTRODUCED  TO  THE  FLEET  THROUGH  THE  RSD  CYCLE  WITH 
THE  NAVY  FREQUENTLY  PARTICIPATING  IN  OR  PROVIDING  FUNDING  FOR 
THE  DESIGN  PROCESS.  IN  MANY  CASES,  THE  NAVY  ACTUALLY  ACQUIRES 
A  MAJORITY  OF  THE  TECHNICAL  DATA  OR  THE  RIGHTS  TO  THAT  DATA, 


MOST  OF  THESE  EQUIPMENTS  FALL  INTO  THE  ELECTRONIC  OR  ORDNANCE 
CATEGORIES.  HOWEVER,  THERE  ARE  SOME  HULL,  MECHANICAL  AND 
ELECTRICAL  (HM&E)  EQUIPMENTS  SUCH  AS  PROPULSION  GAS  TURBINES, 

WHICH  ALSO  FALL  INTO  THIS  GOVERNMENT  FURNISHED  CATEGORY. 

CONTRACTOR  FURNISHED  EQUIPMENT  IS  SUPPLIED  BY  THE  SHIPBUILDER 
TO  MEET  PERFORMANCE  SPECIFICATIONS  CALLED  OUT  IN  THE  SHIPBUILDING 
CONTRACT.  THESE  ARE  FREQUENTLY  OFF-THE-SHELF,  COMMERCIAL,  MARINE 
APPLICABLE  HM&E  EQUIPMENTS,-  BUT  NOT  ALWAYS.  IN  RECENT  YEARS, 

WE  HAVE  SEEN  MORE  SMALL  ELECTRONIC  ITEMS,  INTERCONNECTING 
DEVICES,  REMOTE  CONTROL  UNITS  AND  OTHER  PERFORMANCE  SPECI¬ 
FICATION  ITEMS  BEING  PROVIDED  BY  THE  SHIPBUILDER.  THE  MAIN 
POINT  HERE  IS  THAT  ALMOST  ALL  CONTRACTOR  FURNISHED  EQUIPMENT 
IS  PROCURED  TO  PERFORMANCE  SPECIFICATIONS  WITH  LITTLE  TO  NO 
STANDARDIZATION.  SINCE  NAVY  GENERALLY  HAD  NO  PART  IN  THE 
DEVELOPMENT  OF  THESE  EQUIPMENTS,  AND  DOES  NOT  NORMALLY  CONTROL 
THE  EQUIPMENT  DESIGN,  THE  GOVERNMENT  GENERALLY  DOES  NOT  OWN  THE 
RIGHTS  TO  TECHNICAL  DATA,  AND  FREQUENTLY  THE  EQUIPMENT  MANUFACTURER 
REFUSES  TO  SELL  SUCH  DATA  TO  NAVY. 

LAST  YEAR,  I  USED  A  SIMILAR  PREAMBLE  TO  LEAD  INTO  MY  TWO 
PRINCIPAL  THEMES  -  COMPETITION  AND  COOPERATION. 


YOU  ARE  ALL  AWARE  OF  THE  INCREASING  PRESSURES  PLACED  ON 
THE  DEPARTMENT  OF  DEFENSE  BY  THE  CONGRESS  TO  INCREASE  COMPETITION 
FOR  SPARE  PARTS.  YOU  HAVE  ALL  BEEN  EXPOSED  TO  A I  LEAST  SOME  OF 
THE  TELEVISION  AND  PRINT  MEDIA  EXPOSES  AND  THE  EXAMPLES  GIVEN  WHICH 
WERE  INTENDED  TO  SHOW  MILITARY  WASTE.  YOUR  COMPANY  MAY  HAVE 
BEEN  ONE  OF  THOSE  ACCUSED  OF  PRICE  GOUGING  AND  EXCESSIVE 
PROFITEERING  ON  THE  SALE  OF  SPARE  PARTS  TO  THE  MILITARY. 

IN  MANY  OF  THE  EXAMPLES,  THE  EXPOSE  WAS  CORRECT.  COMPETING 
THE  ITEM  WOULD  HAVE  RESULTED  IN  A  LOWER  PRICE.  THEN,  WHY 
DIDN'T  WE,  OR  YOU  WHEN  YOU  PURCHASED  IT  FOR  US,  COMPETE  THE 
ITEM?  I  DID  NOT  ATTEMPT  TO  ANSWER  THAT  QUESTION  FOR  ALL 
CASES  LAST  YEAR  AND  I  AM  NOT  GOING  TO  ATTEMPT  TO  DO  SO  NOW, 

BUT  I  DID  MENTION  ONE  MAJOR  REASON.  THE  OBSTACLE  TO 
COMPETITION  OF  WHICH  I  SPOKE  WAS  THE  LACK  OF  ADEQUATE 
TECHNICAL  DOCUMENTATION. 

I  TOLD  YOU  LAST  YEAR  THAT  ALL  TOO  OFTEN,  THE  TECHNICAL 
DATA  DELIVERED  TO  THE  NAVY  DID  NOT  DISCLOSE  SUFFICIENT  DETAIL 
TO  SUPPORT  REPROCUREMENT  OF  IDENTICAL  SPARE  AND  REPAIR  PARTS 
FROM  OTHER  THAN  THE  PRIME  CONTRACTOR.  I  ALSO  TOLD  YOU  THAT  THIS 
WAS  THE  USUAL  SITUATION  WITH  REGARD  TO  CONTRACTOR  FURNISHED 


EQUIPMENT,  BUT  THAT  IT  WAS  ALSO  FREQUENTLY  THE  CASE  WITH 
GOVERNMENT  FURNISHED  EQUIPMENT,  EVEN  THOUGH  THE  NAVY 
SUPPOSEDLY  BOUGHT  THE  REQUIRED  DATA,  MORE  ON  THIS  LATER,  ALSO. 

LAST  YEAR  I  ASKED  A  NUMBER  OF  QUESTIONS  WHICH  I  OBVIOUSLY 
DIDN'T  EXPECT  TO  BE  ANSWERED  THEN.  HOWEVER,  OVER  THE  PAST  YEAR 
I  HAVE  GOTTEN  ANSWERS,  IN  ONE  FORM  OR  ANOTHER  TO  MOST  OF  THOSE 
QUESTIONS.  I'M  GOING  TO  REPEAT  SOME  OF  THOSE  QUESTIONS,  AND 
PROVIDE  SOME  ANSWERS  BASED  ON  MY  OBSERVATIONS. 

Q.  HOW  MANY  OF  YOUR  COMPANIES  ASSIGN  YOUR  OWN  PART  NUMBER 
TO  ALL  PARTS  IN  EQUIPMENT  YOU  PRODUCE  EVEN  THOUGH  YOU  DO  NOT  MAKE 
ALL  THE  PARTS  YOURSELF  BUT  PURCHASE  THEM  FROM  SOME  VENDOR  OR 
VENDORS? 

A.  AFTER  ASKING  THIS  QUESTION  I  HAD  MANY  OF  YOU  TELL  ME 
THAT  YOUR  COMPANY  ASSIGNED  ITS  OWN  PART  NUMBER  FOR  INTERNAL 
IDENTIFICATION  AND  CONTROL.  THAT  CERTAINLY  IS  A  LOGICAL  AND 
VALID  REASON,  AND  ONE  WITH  WHICH  I  AGREE.  HOWEVER,  WHAT  WE  HAVE 
FOUND  IS  THAT  IN  TOO  MANY  CASES  THE  ONLY  PART  NUMBER  WHICH  IS 
SUPPLIED  TO  US  IS  THE  PRIME  EQUIPMENT  MANUFACTURER'S  PART 
NUMBER.  ALL  TO  FREQUENTLY  THE  IDENTITY  OF  THE  ACTUAL 


MANUFACTURER  OF  THE  PART  IS  NOT  MADE  VISIBLE,  WE  HAVE  ALSO  HAD 
INSTANCES  WHERE  THE  PRIME  WOULD  NOT  PROVIDE  THE  IDENTITY  OF  HIS 
SOURCES.  THIS  HAS  MOSTLY  BEEN  WITH  MANUFACTURERS  OF  COMMERCIAL 
MARINE  MECHANICAL  OR  ELECTRICAL  EQUIPMENTS.  WE  HAVE  ALSO  HAD 
CASES  BROUGHT  TO  OUR  ATTENTION  WHERE  A  SUPPLIER  CAME  TO  US  STATING 
HE  MADE  A  PART  FOR  AN  EQUIPMENT  MANUFACTURER  WHEN  THAT  MANUFACTURER 
HAD  INDICATED  THAT  HE  MADE  THE  PART  HIMSELF.  WE  ARE  STILL 
INVESTIGATING  A  COUPLE  OF  THESE  SITUATIONS. 

SO  IN  ANSWER  TO  MY  QUESTION,  I  WOULD  SAY  THAT  MOST  COMPANIES 
WHO  ASSIGN  THEIR  OWN  PART  NUMBERS  DO  SO  FOR  VALID  REASONS. 

ALTHOUGH  SOME,  GENERALLY  UNINTENTIONALLY,  HAVE  ALLOWED  THEIR 
INTERNAL  PROCEDURES  AND  CONTROLS  TO  MASK  THE  ACTUAL  SOURCE  OF 
PARTS  IN  DATA  SUPPLIED  TO  THE  NAVY.  UNFORTUNATELY,  HOWEVER, 

THERE  ARE  SOME  WHO  INTENTIONALLY  WITHHOLD  THIS  INFORMATION. 

Q.  HOW  MANY  OF  YOUR  COMPANIES  PURPOSELY  LEAVE  SOME  OF  THE 
DETAILS  OF  A  MANUFACTURING  PROCESS,  QA  REQUIREMENT,  TEST  PROCEDURE 
OR  MATERIALS  REQUIREMENT  OFF  A  PART  DRAWING  SO  WE  WILL  HAVE  TO 
COME  BACK  TO  YOU  TO  BUY  THE  PART? 

A.  UNFORTUNATELY,  FEW  PARTS  DRAWINGS  WHICH  WE  HAVE  REVIEWED 


ARE  TOTALLY  ADEQUATE  FOR  UNLIMITED  COMPETITIVE  PROCUREMENT, 

FREQUENTLY  SOME  OTHER  DRAWING  OR  PROCESS  OR  PROCEDURAL  INSTRUCTION 
REQUIRED  TO  MAKE  AND/OR  TEST  THE  PART  IS  REFERENCED,  BUT  THIS 
DOCUMENTATION  HAS  NOT  BEEN  PROVIDED  TO  THE  NAVY.  ALTHOUGH  MOST 
CONTRACTORS  HAVE  BEEN  COOPERATIVE  IN  SUPPLYING  US  WITH  THE 
ADDITIONAL  REQUIRED  DOCUMENTATION,  IN  MANY  CASES  OUR  ATTEMPTS 
TO  OBTAIN  THE  MISSING  DOCUMENTATION  HAVE  MET  WITH  RESISTANCE, 

EITHER  THE  DOCUMENTATION  IS  "NO  LONGER  AVAILABLE,"  CLAIMED  AS 
PROPRIETARY,  OR  AN  EXORBITANT  PRICE  IS  QUOTED.  IN  SOME  OF  THESE 
CASES,  WE  HAVE  DEVELOPED,  OR  PLAN  ON  DEVELOPING,  THE  REQUIRED 
ADDITIONAL  DRAWINGS  OR  PROCEDURES  OURSELVES  USING  OTHER  DOCUMENTATION 
AND  TECHNICAL  RESOURCES  AVAILABLE  TO  USE.  IN  A  SENSE,  A  FEW  OF 
THESE  INSTANCES  HAVE  BEEN  ALMOST  COMICAL  BECAUSE  AS  WE  INVESTIGATED 
WE  HAVE  FOUND  THE  IDENTICAL  PART  IN  QUESTION  USED  ELSEWHERE,  IN 
OTHER  EQUIPMENT  MANUFACTURED  BY  THE  RECALCITRANT  COMPANY  OR  IN 
ANOTHER  PRIME'S  EQUIPMENT,  AND  IDENTIFIED  BY  ANOTHER  STOCK  NUMBER 
SUPPORTED  BY  COMPLETELY  ADEQUATE  DOCUMENTATION  WITHOUT  RESTRICTIONS. 
THIS  SUPPORTS  THE  NEED  FOR  A  UNIVERSAL  IDENTIFICATION  AND  CONTROL 
SYSTEM  (UNICS).  RIGHT,  TED?  SO  IN  THIS  INSTANCE,  THE  VERY 
SITUATION  WHICH  WE  ARE  TRYING  TO  SOLVE  ELSEWHERE.-  THAT  OF 


MULTIPLE  IDENTIFICATION  OF  PARTS  AND  THE  MULTIPLE  ASSIGNMENT  OF 
STOCK  NUMBERS:  ALLOWED  US  TO  OBTAIN  REQUIRED  DOCUMENTATION. 

HOWEVER,  IT  FURTHER  RAISES  QUESTIONS  AS  TO  HOW  MUCH  DOCUMENTATION 
DUPLICATION  AND  REDUNDANT  DATA  DOES  EXIST.  IF  WE  BETTER  IDENTIFIED 
PARTS  AS  THEY  ARE  BROUGHT  INTO  THE  SUPPLY  SYSTEM  AND  AVOIDED 
IDENTIFICATION  DUPLICATION,  WE  COULD  TAKE  A  VERY  SIGNIFICANT  STEP 
WHICH  WOULD  REDUCE  TECHNICAL  DOCUMENTATION  COSTS  AND  HAVE  THE 
POTENTIAL  OF  FURTHER  REDUCING  SPARE  PARTS  COSTS. 

BY  AND  LARGE  MOST  COMPANIES  HAVE  BEEN  COOPERATIVE  AND 
REASONABLE,  BUT  UNFORTUNATELY,  SOME  HAVE  NOT  BEEN.  SOME  LOOK 
UPON  MILITARY  BUSINESS  AS  SUCH  A  SMALL  PART  OF  THEIR  TOTAL  SALES 
THAT  THEY  FEEL  THEY  DON'T  NEED  TO  DO  ANYTHING  SPECIAL  FOR  THAT 
MILITARY  BUSINESS  EVEN  THOUGH  WE  PAY  FOR  THE  EXTRAS.  SOME  WOULD 
PREFER  NOT  TO  HAVE  OUR  BUSINESS  AT  ALL.  I  SUBMIT  THAT  WITHOUT 
THAT  SMALL  PERCENTAGE  OF  BUSINESS  WHICH  COMES  FROM  THE  MILITARY, 
THOSE  COMPANIES  MIGHT  ONE  DAY  HAVE  NO  BUSINESS  AT  ALL. 

Q.  HOW  MANY  OF  YOUR  COMPANIES  CONSCIOUSLY  STRIVE  TO  GET  YOURSELF 
INTO  THE  POSITION  OF  BEING  THE  SOLE  SOURCE  FOR  SPARE  PARTS  AND 
THEN  CHARGE  EXCESSIVELY  HIGH  PRICES  FOR  THOSE  PARTS? 


a.  I  HATE  TO  SAY  THIS,  AND  I  REALLY  HOPE  I'M  WRONG,  BUT 
JUDGING  FROM  THE  AMOUNT  OF  TECHNICAL  DOCUMENTATION  REVIEWED  BY 
MY  PEOPLE  WHICH  HAS  BEEN  JUDGED  AS  INADEQUATE  FOR  COMPETITIVE 
PROCUREMENT,  IT  APPEARS  THAT  QUITE  A  FEW  EQUIPMENT  MANUFACTURERS 
HAVE  IN  ONE  WAY  OR  ANOTHER  IDENTIFIED  THEMSELVES  AS  THE  SOLE 
SOURCE  FOR  MANY  SPARE  PARTS  AND  HAVE,  IN  MANY  CASES,  MISPRICED 
THOSE  PARTS  WE  HAVE  IDENTIFIED,  MANY  OF  THE  PARTS  IN  THIS 
CATEGORY  THAT  COULD  READILY  BE  MADE  BY  OTHER  MANUFACTURERS  GIVEN 
ADEQUATE  DRAWINGS  AND  OTHER  DOCUMENTATION.  AS  A  RESULT  OF  ALL 
THE  VISIBILITY  OF  AND  PRESSURES  ON  SPARE  PARTS  ISSUES,  THIS 
SITUATION  SEEMS  TO  BE  CHANGING. 

Q.  HOW  MANY  OF  YOUR  COMPANIES  PROFIT  MORE  ON  GOVERNMENT  SALES 
THAN  COMMERCIAL  SALES? 

A.  I  DON'T  REALLY  WANT  TO  ATTEMPT  TO  ANSWER  THIS  QUESTION 
BECAUSE  TO  DO  SO  COULD  GET  ME  INTO  TROUBLE.  I'M  ON  SHAKEY  GROUND 
HERE  BECAUSE  DEFINITIVE  DATA  IS  HARD  TO  COME  BY.  HOWEVER,  THERE 
IS  SOME  EVIDENCE  WHICH  SUGGESTS  THAT  SOME  COMPANIES  HAVE  SOLD 
PARTS  TO  THE  MILITARY  AT  HIGHER  PRICES  THAN  THEY  CHARGE  THEIR 


COMMERCIAL  CUSTOMERS  FOR  THE  SAME  PARTS.  FORTUNATELY,  IT  DOES 
NOT  APPEAR  AS  THOUGH  THIS  PRACTICE  IS  WIDESPREAD.  AND,  I  WOULD 
EXPECT  THAT  IT  WILL  SOON  DISAPPEAR  ALTOGETHER  AS  A  RESULT  OF 
MEDIA  VISIBILITY  OF  SPARE  PARTS  ISSUES. 

Q.  WHY  SHOULD  THE  MILITARY  BE  PLACED  IN  THE  POSITION  OF  BUYING 
SPARE  PARTS  ONLY  FROM  YOUR  COMPANY  UNLESS  YOU  BRING  SOME  SPECIAL 
"MAGIC"  TO  THAT  PARTY? 

A.  THE  SIMPLE  ANSWER  IS  THAT  THE  MILITARY  SHOULD  NOT  BE 
PLACED  IN  SUCH  A  POSITION.  BUT  ON  THE  OTHER  HAND,  THE  PROCUREMENT 
SYSTEM  MUST  ALLOW  FOR  LIMITING  THE  PURCHASE  OF  SPARE  PARTS  TO 
PRIME  EQUIPMENT  MANUFACTURERS  WHEN  IT  IS  TECHNICALLY  APPROPRIATE 
TO  DO  SO. 

Q.  WHY  SHOULD  THE  MILITARY  PAY  YOUR  COMPANY  SIMPLY  TO  PASS  AN 
ORDER  FOR  SPARE  PARTS  THROUGH  TO  ONE  OF  YOUR  VENDORS? 

A.  OBVIOUSLY,  THERE  IS  A  LEGITIMATE  COST  ASSOCIATED  WITH  ANY 
ORDER  PASSED  THROUGH  ONE  COMPANY  TO  ANOTHER.  BUT,  WHY  PASS  THE 
ORDER  THROUGH  THE  FIRST  COMPANY?  WHY  NOT  GO  DIRECT  TO  THE  ACTUAL 
MANUFACTURER  OF  THE  PART?  THIS  IS,  OF  COURSE,  WHAT  SHOULD  BE 
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DONE.  IN  FACT,  SOME  COMPANIES  HAVE  NOW  ESTABLISHED  A  POLICY 
THAT  THEY  WILL  REJECT  ANY  ORDER  FROM  THE  NAVY  FOR  A  PART  WHICH 


THEY  DO  NOT  MAKE  THEMSELVES.  HOWEVER,  IN  ORDER  TO  60  DIRECT  TO  < 

MANUFACTURERS'  PARTS  VENDORS,  WE  MUST  KNOW  WHO  THEY  ARE. 

MANY  OF  YOUR  COMPANIES  HAVE  RECENTLY  BEGUN  TO  PROVIDE  LISTS  OF  « 

VENDORS  TO  THE  NAVY  OR  HAVE  AGREED  TO  DO  SO.  HOWEVER,  MOST  OF 
THE  LISTS  RECEIVED  THUS  FAR,  IN  MY  OPINION,  INVOLVE  A  CERTAIN  « 

AMOUNT  OF  RISK  SINCE  ONLY  FSCMs  AND  PART  NUMBERS  HAVE  BEEN  PROVIDED. 

THIS  IS  GENERALLY  INADEQUATE  SINCE  IT  PROVIDES  US  WITH  LITTLE  OR  NO  '« 

TECHNICAL  INFORMATION  ON  THE  PART  AND  DOES  NOT  INSURE  THAT  WE  WILL 
ALWAYS  BE  ABLE  TO  BUY  THE  ACTUAL  PART  USED  IN  THE  EQUIPMENT  UNDER  » 

THAT  PART  NUMBER.  MY  CONCERNS  SEEM  TO  HAVE  BEEN  HEEDED  BY  THE 
SUPPLY  SYSTEM.  SUCH  LISTS  BY  THEMSELVES  WILL  NO  LONGER  BE  SOLICITED.  *P 
IN  THE  FUTURE,  SPCC  INTENDS  TO  ASK  FOR  AT  LEAST  THE  MINIMUM  TECHNICAL 
DOCUMENTATION  AN  EQUIPMENT  MANUFACTURER  WOULD  INVOKE  IN  HIS  PURCHASE  f 
ORDER.  THIS  IS  AN  AREA  WHERE  WE  NEED  INCREASED  COOPERATION  IN  THE 
FUTURE.  • 

THUS  FAR,  I  HAVE  CHASTIZED  INDUSTRY  FOR  THE  GENERAL  INADEQUACY 
OF  TECHNICAL  DOCUMENTATION  FOR  COMPETITIVE  PROCUREMENT  OF  SPARE  • 

PARTS.  BUT,  THE  NAVY  AND  THE  OTHER  SERVICES  EACH  SHARE  IN  THE 
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CAUSES  OF  THIS  INADEQUACY,  IN  MANY  CASES,  WE  HAVE  FAILED  TO 

ADEQUATELY  SPECIFY  TECHNICAL  DOCUMENTATION  REQUIREMENTS  IN 

ACQUISITION  CONTRACTS,  OR  WE  HAVE  FAILED  TO  INSURE  THAT  CONTRACTORS 

FULLY  MET  ALL  DOCUMENTATION  REQUIREMENTS.  IN  MY  OPINION  MANY  OF 

THE  MIL-STANDARDS  AND  MIL-SPECS  ARE  UNCLEAR  IN  THEIR  REQUIREMENTS 

AND  IN  SOME  CASES  ARE  DOWN  RIGHT  AMBIGUOUS.  MANY  OF  OUR  CONTRACTS 

LEAVE  A  LOT  TO  BE  DESIRED  AS  FAR  AS  CLARITY  AND  SIMPLICITY  ARE 

CONCERNED.  IF  THE  MILITARY  SERVICES  REALLY  ARE  SERIOUS  ABOUT 

WANTING  TECHNICAL  DOCUMENTATION  WHICH  IS  FULLY  ADEQUATE  FOR  UNLIMITED 

COMPETITION,  THEN  WE  HAVE  A  LOT  TO  DO  TO  CLEAN  UP  OUR  ACT. 

WHAT  ABOUT  THE  FUTURE?  HOW  IS  THIS  DILEMMA  GOING  TO  BE 

RESOLVED?  IN  MY  OPINION,  REAL  AND  LASTING  SOLUTIONS  WILL  TEST  THE 

FLEXIBILITY  OF  BOTH  THE  MILITARY  AND  INDUSTRY  AS  MANY  OF  THE 

REQUIRED  ACTIONS  WILL  NOT  ONLY  NECESSITATE  INDEPENDENT  ACTION  BY 
EACH  BUT  MANY  ACTIONS  WILL  ALSO  REQUIRE  CLOSE  COOPERATION  AND 

COORDINATION  BETWEEN  THE  MILITARY  AND  INDUSTRY.  IMPROVED  COOPERATION 

AND  COORDINATION  BETWEEN  THE  MILITARY  AND  INDUSTRY  ARE,  IN  FACT, 

THE  KEYS  TO  THE  FUTURE.  HOWEVER,  WE  MUST  BE  CAREFUL  THAT  SUCH  IS 

NOT  VIEWED  AS  "COLLUSION  WITHIN  THE  MILITARY-INDUSTRIAL  COMPLEX." 
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LAST  OCTOBER  I  HAD  THE  OPPORTUNITY  TO  CHAIR  A  PANEL  ON 
"REDUCING  THE  COST  OF  SPARE  PARTS"  AT  THE  DOD  STANDARDIZATION 
CONFERENCE  AT  LEESBURG,  VA.  I  WAS  FORTUNATE  TO  HAVE  HAD  SOME  VERY 
SENIOR  REPRESENTATIVES  OF  INDUSTRY  AS  WELL  AS  REPRESENTATIVES, 

BOTH  UNIFORMED  AND  CIVILIAN,  OF  THE  MILITARY  ON  MY  PANEL.  I  THOUGHT 
WE  HAD  SOME  VERY  GOOD  PRESENTATIONS  AND  SOME  LIVELY  DISCUSSIONS. 

WE  MADE  A  NUMBER  OF  RECOMMENDATIONS,  ALL  OF  WHICH  WERE  ACCEPTED  AS 
CONFERENCE  ACTION  ITEMS  IN  THE  FINAL  REPORT.  MOST  OF  THESE  ARE  AT 
THE  DOD  LEVEL  FOR  ACTION.  I  MENTION  THIS  BECAUSE  MANY  OF  THOSE 
RECOMMENDATIONS,  NOW  ACTION  ITEMS,  DEAL  WITH  GREATER  INTERACTION 
PETWEEN  THE  MILITARY  AND  INDUSTRY  IN  GENERAL,  AND  SPECIFICALLY 
WITH  THE  ESTABLISHMENT  OF  SOME  AD  HOC  DOD/INDUSTRY  STUDY  GROUPS 
TO  ADDRESS  TECHNICAL  DOCUMENTATION  REQUIREMENTS  AND  PROCUREMENT 
PRACTICES.  THE  ADPA  TECHNICAL  DOCUMENTATION  DIVISION  NEEDS  TO 
SUBTLY  USE  WHATEVER  INFLUENCE  YOU  MAY  HAVE  TO  KEEP  THESE  ITEMS  ALIVE 
AND  WORKING. 
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WE  NEED  TO  ALSO  COLLECTIVELY  LOOK  AT  COSTS  OF  TECHNICAL 
DOCUMENTATION  AND  INSURE  THAT  EFFORTS  ARE  TAKEN  TO  REDUCE 
THOSE  COSTS  TO  THE  MINIMUM,  TOGETHER  WE  MUST  MAKE  SURE  THAI  THE 
TECHNICAL  DOCUMENTATION  THAT  THE  MILITARY  BUYS,  WHATEVER  THE 
REASON,  BE  IT  DESIGN,  MAINTENANCE,  OR  INITIAL  AND  REPROCUREMENT 
SPARE  PARTS  SUPPORT,  IS  COMPLETELY  ADEQUATE  FOR  THE  INTENDED 
PURPOSE.  WE  MUST  REVIEW  TECHNICAL  DOCUMENTATION  REQUIREMENTS  TO 
INSURE  MINIMUM  REDUNDANCY  AND  MAXIMUM  USABILITY.  WE  NEED  TO, 

AS  ONE  OF  MY  ENGINEERS  IS  FOND  OF  SAYING,  "ALWAYS  CALL  THE  SAME 
THING,  THE  SAME  THING."  WE  NEED  TO  USE  THE  SIMPLIST  NAMES  FOR 
PARTS.  WE  MUST  STOP  CALLING  A  SIMPLE  MECHANICAL  PENCIL  A  "MARKING 
STYLUS"  AND  PRICING  THE  "STYLUS"  AT  $154.00  WHEN  THE  ITEM  IS  IN 
FACT  A  NAME  BRAND  MECHANICAL  PENCIL  PRICED  AT  ABOUT  $3.00. 

THIS  IS  AN  ACTUAL  CASE  FOR  WHICH  I  HAVE  THE  EVIDENCE  WITH  ME. 

NOT  ONLY  THAT,  BUT  THE  DRAWING  HAS  A  NOTE  TO  DISCARD  THE  PLASTIC 
CASING.  WE  MUST  INCREASE  AWARENESS  THROUGHOUT  PROCUREMENT 
ACTIVITIES  OF  THE  REAL  TECHNICAL  DOCUMENTATION  REQUIREMENTS 
NECESSARY  FOR  UNLIMITED  C0MPETI1I0N  SO  THAT  THESE  REQUIREMENTS 
CAN  BE  APPROPRIATELY  APPLIED. 
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WE  MUST  APPRAISE  THOSE  IN  SENIOR  POSITIONS  THAT  IT  MAY  AT  TIMES 


COST  MORE  TO  OBTAIN  OR  DEVELOP  REQUIRED  TECHNICAL  DOCUMENTATION 
THAN  WE  MIGHT  EXPECT  TO  SAVE  THROUGH  COMPETITION.  WE  MUST 
RESIST  THE  PRESSURES  TO  COMPETE  AT  ANY  COST.  COMPETITION  MUST 
PRESENT  A  POTENTIAL  FOR  SIGNIFICANT  SAVINGS  WHEN  ALL  DOCUMENTATION 
COSTS  ARE  CONSIDERED  OR  ELSE,  IN  MY  OPINION,  IT  IS  NOT  A  VIABLE 
PROCUREMENT  ALTERNATIVE.  ALTHOUGH  I  AM  A  STRONG  SUPPORTER  OF 
INCREASED  COMPETITION,  WE  MUST  NOT  LET  THOSE  WHO  ADVOCATE 
"COMPETITION  AT  ANY  COSTS"  WIN  OUT  OVER  THOSE  WHO  SUPPORT 
"TECHNICAL  COMPETENT  COMPETITION."  A  CASE  CAME  TO  MY  ATTENTION 
RECENTLY  WHERE  AN  EQUIPMENT  MANUFACTURER,  WHO  HAD  MADE  A  PARTICULAR 
PART  IN  HIS  SHOP  AND  HAD  BEEN  THE  SOLE  SOURCE  FOR  THAT  PART,  WAS 
PROHIBITED  FROM  BIDDING  ON  A  SOLICITATION  BECAUSE  IT  WAS  SET 
ASIDE  FOR  SMALL  BUSINESS.  TO  TOP  IT  OFF,  THE  PRIME'S  PART  WAS 
PROVIDED  AS  A  SAMPLE.  THIS,  TO  ME,  IS  LUDICROUS! 

BUT,  WE  MUST  FACE  FACTS.  THE  PRESSURES  TO  COMPETE  SPARE 
PARTS  ARE  NOT  GOING  TO  GO  AWAY.  ON  THE  CONTRARY,  I  EXPECT  THAT 
THE  SCREWS  WILL  BE  TIGHTENED  EVEN  MORE  BY  CONGRESS  AND  DOD  NEXT 
YEAR  AND  THE  HEAT  WILL  FURTHER  INCREASE.  IN  ALL  OF  OUR  ACTIONS 
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IN  THE  FUTURE,  WE  MUST  INSURE  THAT  THE  REQUIREMENTS  FOR  TECHNICAL 


DOCUMENTATION  ARE  CLEAR,  CONCISE  AND  REALISTIC.  WE  MUST  AVOID 
REDUNDANCY  AND  DUPLICATION.  ABOVE  ALL,  OUR  ACTIONS,  BOTH 
MILITARY  AND  INDUSTRY,  INDIVIDUALLY  AS  WELL  AS  COLLECTIVELY, 

MUST  BE  CREDIBLE  AND  ABOVE  REPROACH.  OUR  REPUTATIONS  ARE  ON 
THE  LINE. 

IN  CLOSING,  I  WOULD  TELL  YOU  THAT  AS  A  SIMPLE  "SHIP  DRIVER" 

MY  BOTTOM  LINE  ALWAYS  IS  IMPROVED  SUPPORT  FOR  THE  FLEET.  WE 
FACE  SOME  SIGNIFICANT  CHALLENGES  AS  FAR  AS  RESOLVING  THE  ISSUES 
RELATING  TO  THE  PRESENT  SITUATION  WHERE  MUCH  TECHNICAL  DOCUMEN¬ 
TATION  IS  NOT  ADEQUATE  FOR  FULLY  COMPETITIVE  PROCUREMENT  OF 
SPARE  PARTS.  BUT  THERE  REALLY  HAVEN'T  BEEN  MANY  CHALLENGES 
THAT  THE  MILITARY  AND  INDUSTRY  HAVEN'T  BEEN  ABLE  TO  SOLVE  WHEN 
WE  WORK  TOGETHER  TOWARD  A  COMMON  OBJECTIVE.  THE  OBJECTIVES  HERE 
ARE  COMMON  BECAUSE  OF  THE  ULTIMATE  IMPACT  ON  BOTH  PARTIES, 

THE  MILITARY  AND  INDUSTRY.  WE  HAVE  BOTH  TAKEN  ENOUGH  HITS  AND 
BEEN  GIVEN  ENOUGH  BLACK  EYES  BY  THE  MEDIA  ON  THE  LACK  OF  COMPETITION 
FOR  SPARE  PARTS.  THE  DRIVE  FOR  INCREASED  COMPETITION  IS  HERE 
TO  STAY— AND  WELL  IT  SHOULD.  TO  FILL  OUR  RESPECTIVE  AND 


COLLECTIVE  RESPONSIBILITIES,  WE  NEED  TO  GET  ON  WITH  IMPROVING 


THE  SYSTEM  SO  THAT  MY  BOTTOM  LINE  OF  IMPROVED  SUPPORT  TO  THE 
FLEET  CAN  BE  ACHIEVED. 
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SUMMARY 


This  paper  provides  an  overall  status  report  on  the  TMSS  Program  related 
to  eleven  Joint  Service  Tasks  described  in  the  TMSS  Program  Plan  dated 
July  1983.  Primary  emphasis  is  on  the  status  of  Task  1  and  Task  4  ;  Task 
1  being  the  highest  priority  task  designed  to  develop  a  single  set  of  DOD 
Requirements  documents  for  the  writing  of  operator  and  maintenance  equip¬ 
ment  manuals. 


INTRODUCTION  -  Technical  Manual  Specifications  and  Standards  (TMSS)  is 
a  Department  of  Defense  (DOD)  Standardization  Program.  Policies,  pro¬ 
cedures  and  instructions  pertinent  to  TMSS  are  contained  in  the  Defense 
Standardization  Manual,  DOD  4120. 3-M. 

PROBLEM  -  (Figure  1)  The  issue  simply  put  is  why  do  we  need  individual 
service  specifications  for  preparation  of  technical  manuals.  Whether 
we  are  developing  individual  service  manuals  or  joint  use  manuals,  it  is 
not  reasonable  to  have  differing  specification  to  cover  the  content  and 
format  of  these  publications.  Under  current  policy,  costs  can  be  driven 
up  when  services  insist  on  their  peculiar  requirements  on  joint  use  manuals. 

For  systems  like  TRI-TAC,  we  have  been  patch  working  together,  through 
time  consuming  negotiations,  specifications  that  could  result  in  poor 
sprvice  to  the  user.  There  should  be  no  overriding  reason  why  a  single 
set  of  DOD  specifications  for  TM's/TO's  and  parts  manuals  cannot  be  devel¬ 
oped.  We  currently  list  almost  200  specifications  used  to  develop  TM's/ 

TO's  with  very  few  of  these  being  joint  service  specifications. 

(Figure  2)  In  a  Time  cover  story  dated  7  Mar  83,  related  to  high  weapons 
costs  within  DOD,  There  was  a  highlighted  boxed  section  pertaining  to 
military  specs.  It  talked  about  the  number  of  specs  related  to  T-shirts, 
chewing  gum,  and  food  sauce.  The  story  could  very  well  have  listed  our 
TM  specs. 

PROGRAM  PLAN  -  (Figure  3)  However,  we  do  have  an  on-going  program  designed 
to  overcome  the  problem  and  to  consolidate  the  individual  service  documents 
into  Joint  Use  DOD  Specifications  approved  by  all  services  and  OSD.  The 
current  plan  was  approved  and  published  in  July  1983  and  includes  11  Joint 
Service  Tasks.  This  Program  Plan  is  a  complete  revision  of  the  preceding 
plan  dated  January  1980. 

WORKING  GROUP  -  (Figure  4)  To  effectively  implement  the  TMSS  Program  Plan 
and  cope  with  the  complex  job  of  developing  single  sets  of  DOD  requirements 
documents,  a  TMSS  Work  Group  was  formed.  This  work  group  consists  of 
personnel  from  every  service  who  are  extremely  knowledgeable  in  the  Technical 
Manuals  Field.  The  group  was  formed  in  1980  and  has  met  on  a  frequent, 
periodic  basis  since  that  time.  Continuity  of  representation  has  been  an 
essential  factor  in  the  effectiveness  of  the  group. 

JOINT  SERVICE  TASKS  -  (Figure  5)  The  11  Joint  Service  Tasks  are  depicted  in 
this  chart  with  summary  titles.  The  task  with  the  highest  potential  payoff, 
and  thus  priority  one,  is  Task  1  in  which  we  have  already  started  work  to 
develop  a  single  set  of  specifications  and  DID's  for  the  preparation  of  operator 
and  organizational  and  intermediate  maintenance  manuals.  Tasks  3  and  4  are  the 
responsibility  of  NMC  and  Tasks  6  and  10  will  be  the  responsibilty  of  AFLC. 
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STATUS  -  TASK  1  -  (Figure  6)  Task  1  is  the  keystone  to  the  whole  joint 
service  effort  and  has  the  highest  potential  payoff.  The  work  group  has 
identified  40  specifications  that  are  currently  used  to  develop  operator 
manuals  and  organization  and  intermediate  manuals.  These  40  cover  docu¬ 
ments  from  each  service.  We  used  a  contractor  to  supply  us  with  labor 
intensive  effort  to  identify  and  document  the  common  and  service  peculiar 
requirements  into  technical  data  packages.  We  met  as  a  work  group  with 
the  contractor  on  periodic  in-process  reviews  to  mutually  agree  on  what 
constituted  a  common  or  peculiar  requirement. 

(Figure  7)  We  have  observed  that  when  you  analyze  our  service  specs,  it 
is  apparent  how  close  we  are  in  our  approaches  and  intent.  There  are  very 
many  common  requirements  among  the  various  documents  and  of  course  some 
service  peculiar  requirements.  But  we  are  so  close  in  goals  that  we  are 
most  optimistic  we  can  design  single  DOD  documents. 

(Figure  8)  The  current  status  of  Task  1  is  that  we've  identified  and 
agreed  to  all  operator  manual  and  maintenance  manual  (except  depot) 
common  and  peculiar  requirements  from  the  40  specs.  We've  also  agreed 
to  a  selection  of  common  and  the  best  of  the  peculiar  requirements  for 
inclusion  in  the  final  DOD  documents.  The  first  draft  document  on  opera¬ 
tor  manuals  and  IPB's  is  out  for  final  work  group  concurrence.  The 
organization  and  intermediate  maintenance  manual  documents  are  being 
drafted  right  now.  All  documents  are  to  be  coordinated  during  this  CY  84. 

The  final  documents  are  milestoned  for  completion  early  in  CY  85.  Phase  2 
to  this  task  will  be  to  determine  the  feasibility  of  coming  up  with  a  single 
DOD  document  for  depot  maintenance. 

STATUS  -  TASK  4  -  (Figure  9)  Task  4,  assigned  to  Navy  as  the  lead  for 
implementation,  was  designed  to  investigate  the  development,  implementation, 
and  impact  of  electronic  (digital)  delivery  of  technical  information  to  the 
services  operators  and  maintainers  as  a  substitute  or  supplement  to  hard 
copy  TM's/TO's.  The  first  phase  was  to  determine  the  extent  of  prolif¬ 
eration  of  different  hardware  and  software  systems  planned  or  being  intro¬ 
duced  into  use  by  the  services;  assess  the  need  for  management  control  in 
the  introduction  of  the  technology  and  for  specifications  and  standards 
for  the  hardware  and  software  systems  involved.  Figure  9  summarizes  the  problems 
resulting  from  lack  of  standardization  of  electronic  TI  as  reported  by  Navy. 

(Figure  10)  A  partial  list  of  automated  or  electronic  display  systems  is 
shown  on  Figure  10.  These  include  systems  designed  to  automate  TM  production, 
to  deliver  technical  information  electronically  and  include  both  hardware 
and  software  in  stages  ranging  from  conceptual  to  operational.  The  prolif¬ 
eration  is  extensive. 

(Figure  11)  The  first  phase  of  Task  4  has  been  completed  as  shown  in  Figure  11. 
The  need  for  management  control  is  obvious  and  the  need  for  specs  and  standards 
for  the  hardware,  software  and  displays  is  also  obvious.  The  next  phase  is 
for  the  working  group  to  recommend  the  TMSS  role  and  the  steps  to  be  taken  to 
effect  standardization. 
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SUMMARY  -  (Figure  12)  At  the  working  level  and  at  the  four  star  level 
(as  evidenced  by  JLC  approval  of  the  TMSS  Program  Plan)  there  is  agree¬ 
ment  that  we  can  achieve  singular  sets  of  DOD  specs/Stds.  The  progress  to 
date  has  been  excellent  due  in  large  part  to  the  successful  operation  of 
the  TMSS  Work  Group.  Most  of  the  joint  service  tasks  will  depend  on  the 
successful  outcome  of  Task  1.  Successful  completion  of  Task  1  will  have 
a  significant  impact  on  the  eventual  outcome  of  Task  4.  The  opportunity 
to  effect  standardization  in  Task  4  is  now,  before  the  rabbits  multiply 
beyond  control . 


VARIOUS  FORMATS  DRIVE  UP  COSTS 
PATCHWORK  COMPROMISES  ILL-SUIT  USER 
ALMOST  200  SPEC’s  FOR  TM’s/TO’s 
VERY  FEW  JOINT  SERVICE  SPECS 


Figure  1 


COVER  STORY 


TIME  MAGAZINE 
MARCH  7,  1983 

“THE  WINDS  OF  REFORM- 
RUNAWAY  WEAPONS  COSTS  PROMPT  A  NEW  LOOK 
AT  MILITARY  PLANNING” 


EXCERPT - 


“TWENTY  FOUR  PAGES  ARE  REQUIRED  TO  LIST 
THE  SPECS  FOR  T-SHIRTS,  15  PAGES  FOR  CHEWING 
GUM,  AND  17  FOR  WORCESTERSHIRE  SAUCE.” 


Figure  2 
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DOD  TECHNICAL  MANUALS  SPECIFICATIONS 
AND  STANDARDS  (TMSS) 


•  ARMY  IS  LEAD  SERVICE 

•  MRSA  IS  LEAD  SERVICE  ACTIVITY 

•  MRSA  COORDINATES  AND  PUBLISHES  DOD  TMSS  PROGRAM  PLAN 


TMSS  WORK  GROUP 

•  US  ARMY  DARCOM  MATERIEL  READINESS  SUPPORT  ACTIVITY 
(LEAD  SERVICE) 

•  HQ  AIR  FORCE  LOGISTICS  COMMAND 

•  HQ  AIR  FORCE  SYSTEMS  COMMAND 

•  NAVAL  SEA  SYSTEMS  COMMAND 

•  NAVAL  AIR  TECH  SVCS  FACILITY 

•  NAVAL  ORDNANCE  STATION 

•  HO  MARINE  CORPS 
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NOTE:  ADDITIONAL  ON-CALL  PARTICIPATION  FROM  ANY 
SOURCE  AS  NEED  ARISES 

Figure  4 
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TASK  1  SINGLE  SET  OF  DOD  SPECS  FOR  TM* 
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2  DATA  ITEM  DESCRIPTIONS  (DIO’s) 
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3  DOD  INDEX  OF  SPECS  AND  STDS 
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4  ELECTRONIC  DATA  DELIVERY 

5  PHASED/PERIODIC  MAINTENANCE 

6  BATTLE  DAMAGE  REPAIR 

7  TM  DATA  BREAKDOWN 
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8  EQUIPMENT  MODS 
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9  LUBE  DATA 
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10  TM  INDEXES 
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JOINT  PAYOFF 


TASK  1  OBIECTIVi  AND  STATUS 


CURRENT 
40  SPECS 
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CONTRACTOR  GUIDED  BY 
JOINT  WORK  GROUP  SORT 
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PECULIAR 

DATA 


JOINT  WORK  GROUP 
PREPARE  SPECS  BY 
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DOD  SPECS 
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OBSERVATIONS 


INNOVATIONS  OF  EACH  SERVICE  SIMILAR 
LESS  TEXT 

MORE  ILLUSTRATIONS 
WRITTEN  TO  TARGET  AUDIENCE 

MANY  COMMON  REQUIREMENTS 

SOME  SERVICE  PECULIAR  REQUIREMENTS 
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TASK  1 

•  ALL  OPERATOR  MANUAL  AND  MAINTENANCE  MANUAL  COMMON 
AND  PECULIAR  REQUIREMENTS  FROM  THE  40  SPECS  HAVE  BEEN 
IDENTIFIED  AND  AGREED  TO  BY  THE  WORKING  GROUP 

•  THE  SELECTION  OF  COMMON  AND  PECULIAR  REQUIREMENTS  HAS 
BEEN  DETERMINED  FOR  INCLUSION  IN  THE  FINAL  DOD  DOCUMENTS 
AND  DRAFT  SPECS  ARE  BEING  WRITTEN 

•  THE  FIRST  DRAFT  SPEC  ON  OPERATOR  MANUALS  AND  IPB’s  IS  OUT 
FOR  FINAL  WORK  GROUP  CONCURRENCE 

•  PLANS  ARE  TO  COORDINATE  ALL  DRAFTS  IN  THIS  CY  84 

•  TARGET  DATE  FOR  FINAL  SPEC  PRINTING  -  EARLY  CY  85 


Figure  8 


PROBLEMS  RESULTING  FROM  LACK  OF  STANDARDIZATION 

OF  ELECTRONIC  Tl 

•  INTRODUCTION  OF  SYSTEMS  UNFIT  FOR  USE  IN  MILITARY 
ENVIRONMENTS 

•  ILS  RENDERED  IMPOSSIBLE  DUE  TO  UNCONTROLLED  PROCUREMENT 
OF  MANY  NON-STANDARD  EQUIPMENTS 

•  INFLATED  COSTS  NOT  ONLY  FOR  INITIAL  BUYS  BUT  FOR  LIFE  CYCLE 
MAINTENANCE 

t 

•  CONTROL  AND  CONFIGURATION  MANAGEMENT  IN 
UNCONTROLLED  PROCUREMENT  OF  ELECTRONIC  Tl  DISPLAY 
SYSTEMS  WOULD  BE  INSUPPORTABLE 

•  INCOMPATIBILITY  OF  EQUIPMENT 

Figure  9 

TASK  4 

PARTIAL  UST  OF  AUTOMATED  OR  ELECTRONIC 
DISPLAY  SYSTEMS  (CONCEPTUAL  TO  OPERATIONAL) 
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TASK  4 


•  ASSESSMENT  HAS  BEEN  MADE  OF  THE  DEVELOPMENT, 
IMPLEMENTATION  AND  IMPACT  OF  ELECTRONIC  DELIVERY  OF 
TECHNICAL  INFORMATION  TO  THE  SERVICES  OPERATORS  AND 
MAINTAINERS 

•  THE  CURRENT  EXTENT  OF  PROLIFERATION  OF  DIFFERENT  HARDWARE 
AND  SOFTWARE  SYSTEMS  PLANNED  OR  BEING  INTRODUCED  HAS 
BEEN  ASSESSED 

•  THE  NEED  FOR  MANAGEMENT  CONTROL  IS  OBVIOUS.  THE  NEED 
FOR  SPECIFICATIONS  AND  STANDARDS  FOR  THE  HARDWARE, 
SOFTWARE  AND  DISPLAYS  IS  ALSO  OBVIOUS 

•  THE  NEXT  PHASE  IN  TMSS  TASK  4  IS  FOR  THE  WORKING  GROUP  TO 
RECOMMEND  THE  TMSS  ROLE  AND  THE  STEPS  TO  BE  TAKEN  TO 
EFFECT  STANDARDIZATION 


Figure  11 


SUMMARY 

•  WITHIN  THE  TM  COMMUNITY,  SERVICES  AGREE  WE  CAN  ACHIEVE 
SINGULAR  SETS  OF  DOD  SPECS/STDS 

•  PROGRESS  TO  ACHIEVE  DOD  DOCUMENTS  HAS  BEEN  EXCELLENT 

•  MOST  OF  THE  TMSS  JOINT  SERVICE  TASKS  WILL  DEPEND  ON 
OUTCOME  OF  TASK  1 

•  SUCCESSFUL  COMPLETION  OF  TASK  1  WILL  BE  OF  SIGNIFICANT 
IMPORTANCE  TO  OUTCOME  OF  TASK  4 

•  THE  OPPORTUNITY  TO  EFFECT  STANDARDIZATION  IN  TASK  4  IS  NOW 


A  NEW  DIMENSION  IN 
INFORMATION  STORAGE  &  RETRIEVAL 


I 


Image  Processing  and  Optical  Disk  Technology 


mnemas 

MANAGEMENT  PHILOSOPHY 

•  Provide  Customer  the  Most  Cost-Effective  Solution 
to  His  Information  Dissemination  Problem 

-  Document  Design 

-  Custom  Application  Software 

-  Custom  Blend  of  Digital  Data,  Graphics,  and  Text 

-  Standalone  Workstation 

-  Workstation  as  Part  of  a  Total  System 


r 
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mnemos 

PRODUCT  CONCEPT 

Mnemos  System  6000  is: 

•  An  Innovative  Integration  of  Various  Process  Technologies... 

-  Electron  Beam  Recording  (EBR) 

•  Laser  Carrier  Grading  (LCG) 

•  Optics 

-  Electronics 

e  ...Which  Merge  Digital  Information  (Text,  Data,  Applications 
Software)  with  High  Resolution  Graphics  (Micro  Miniature 
Images)  on  the  Same  High  Density  Storage  Media... 

e  ...To  Economically  Address  a  Significant  and  Emerging  Market 
for  Large  Scale  Information  Dissemination,  Storage  & 
Retrieval,  and  Manipulation. 
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PRODUCT  CONCEPT  (CONT'D) 

Mnemos  System  6000  Features  and  Characters: 

e  Mnemodisc™: 

-  High  Capacity/High  Resolution  Graphics 

and  Text  Storage 

-  Various  Mixtures  of  Image  and  Digital  Data 

-  Document  Storage  of  Various  Sizes  in 

Vertical  or  Horizontal  Format 


-  Digital  and/or  Optical  Indexing 

-  Archival  Quality 


mnemas 

PRODUCT  CONCEPT  (CONT'D) 

Mnemos  System  6000  Features  and  Characters: 

•  Mnemos  Workstation: 

-Rear  Projection  Display  Module 

-  Microprocessor/Memory/Controls 
-Rapid  Search  &  Retrieval 
-Optional  Communications  Ports 

•  Intelligent  Keyboard 
-Independent  Microprocessor  Memory 
-Digital  Line  Display 
-Typewriter-Like  Keyboard 

-  Fixed  Function  Keys 
-“Soft"  Function  Keys 
-User  Programmable  Functions 
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ELEMENTS  OF  THE  SYSTEM 


Customer 

Solution 


The  Workstation 

mi 


DISC 

Studio 


o 


The  Mnemodisc 


ALLOWABLE 
INDEXING  SCHEMES 


Group  Group  Item  Browse  Helrarchfcal  Keyword 
Name  Name  Name  Search  Search 

Or  Or  Or  _ _ _ 

Number  Number  Number  LJ 


79  VW  Part  Number 

Rabbit  01 1-469-AB 


Door  Handla 
Right  Door 
Latt  Side  Drive 
79  VW 
Rabbit 


EXAMPLE  APPLICATION  - 
POSTAL  SERVICE  COUNTER 


1.  Domestic  Mail  Manual 

2.  International  Mail  Manual 

3.  Zip  Code  Directory 

4.  Financial  Management  Directory 

5.  Post  Office  Manual 

6.  Personnel  Policy  Manual 


Use  Numeric  Keypad  to  Select  One 


of  a  Number  of  Major  Handbooks 


INTERNATIONAL  MAIL  MANUAL 


or 

Type  in  First  Three  Letters 
Of  Country's  Name  - 
"BAH"AMAS 


TABLES  OF  POSTAL  RATES  TO  THE  BAHAMAS 


Weight 

Wot  Over  Rate  s 


Weight 
.  Not  Over  Rate 


KlilS 

12 

13.10 

3" 

$3.10, 

13 

14.10 

4' 

4.10 

14 

15.10 

5 

5.10 

15 

16.10 

6 

6.10, 

s  16 

■17.10 

7 

7.10 

17 

18.10 

8 

8.10 

18 

19.10 

9 

9.10 

<  19 

20.10 

10 

10.10 

20 

21.10 

11 

11.10 

21 

22.10 

y*  ■  •* 

22 

23.10 

•  Pictoral  Display  of  Rates  and  Rate  Categories 

e  Simultaneous  Down  Loading  of  Corresponding 
a  Digital  Inf orma tipn  vju  '  •*  1 

e  Enter  Weight  of  Parcel  Via  Numeric  Keypad 
"  CTO  O-  bR  -O  O  O  D'T)  OO 


'Automatic  from  Scale  Via 
- RS  -  232  Interface - 


9 

\ 


| - — RS  -  232  interface - 1 

e  Automatic  Calculation  of  Total  Postage,  Etc. 
e  Printout  on  Postal  Form 


or 

By  Typing  in  the  Functional  Group  and 
Subfunctional  Code  XXX 


SUMMARY  OF  BENEFITS  FROM  A  MNEMODISC  PARTS  CATALOGUE 


SUMMARY  OF  BENEFITS  FROM  A  MNEMODISC  PARTS  CATALOGUE 


Increased  Profit 
To  Corporate 


Reduced 
Error  Rato 


Lower  Shipping  Smaller  Benefits  Inventory  Automatic 
Costs  Inventory  ^'^Centralization  Ordering 

{ [  Mnemodlsc 
IV  System 

Benefits 
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Andlnlegrfen 


Increased  Productivity 


R«duc«d  Staffing  Lowar  Training  Hlghar Machanic  Improvad 
Raquiramants  Raqmts.  Productivity  Cuatomar  Sarvlca 


tnnemas 


PRODUCT  POSITIONING 

Conventional  Technologies 


Media  Advantages  Disadvantages 

Paper  —Familiar  —  Distribution  Coats 

—  Storage  Space  And 
C08t 

—  Difficult  to  Retrieve 


Micrographics  —  Space  Savings 

—  Distribution  Costs 


—  Difficult  to  Use 

—  Serial 

—  Very  Limited  Index 
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PRODUCT  POSITIONING 

Alternative  Technologies 


Media  Advantages  Disadvantages 

-Magnetic  Storage  —  System  Integration  —Storage  Costs 

(Centralized  —Fast  Access  (esp  if  Hlgh-lmage 

Computer  — Searchable  Text  Content) 

Database)  — Communication  Costs 

-Optical  Disc  —  High  Storage  Density  -High-Cost  Display 

of:  -High-Bit  Error  Rate 

~  Text  —Communication  Costs 

-  Graphics 

-Video  Disc  —High  Storage  Density  —Low  Resolution 

of:  (Limited  by 

-  Color  Pictures  FCC  Approved  TV 

-  Motion  Video  Standards) 

-  Sound 

—  Low  Replica  Cost 


Conventional 

Technologies 


Paper 


PRODUCT  POSITIONING 


System  Integration 


Alternative 

Technologies 


Fast  Access 


Familiar 


mtlBinos  System 
6000 


Searchable 

^•"Text 

\  High 
\  Storage/ 


Density 


Storage 


Optical 


Space  Savings 
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Price  Performance 


Videodisc 


ELEMENTS  OF  THE  TECHNOLOGY 


DATA  BASE 
PREPARATION 
Page  Composition 


Paper 


Data  ^ 

Agfilte.p.llffn?  »(tsp>W 

Software 


Approach 


Floppy 


INFORMATION 

DISSEMINATION 

Mastering 


A  Glass 
0  1  Master 


STORAGE, 
RETRIEVAL  AND 
MANIPULATION 

Intelligent  Workstation 


Replica  Discs 


e  Publishing  A 
Composition 
•  Application 
Software 
Development 


Stamper 

•  Electron  Beam 

Recording 

•  Laser  Carrier  Grading 
e  Materials 

e  Pressing  Process 


e  Optics 

•  /U.  Electronics 

•  User  Interface 

•  Communications 


LAYOUT  OF  THE  MNEMO  DISC 


LAYOUT  OF  THE  MNEMO  DISC 


DISC  STUDIO 


Magnate 
StudloTapo  from 
Data  Studio 


Electron  team 
Racordar 


mnetnas 

LASER  CARRIER  GRATING  OPTICAL  RECORDING 


No  Light 
To  Screon 


SESSION  4 


Workshop  Coordinator 

MR.  T.  L.  GOLMIS 
Hughes  Aircraft  Company 


See  sections  V,  W,  and  X  for  Session  4  workshop  summaries 
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COMPUTER-AIDED  EDITING  -  PRESENT  AND  FUTURE 


Dr.  J.  Douglas  Kniffin,  Westinghouse  Electric  Corporation 


This  paper  describes  computer-aided  editing  systems  which  analyze 
English  text  and  suggest  improvements.  The  systems  described  are  vastly 
different  from  the  familiar  word  processing  programs  which  permit  editing 
changes  such  as  insertions  and  deletions  of  characters,  words,  or  lines 
of  text.  These  new  systems  analyze  the  style  and  style  difficulty  of 
text  and  provide  feedback  to  writers  and  editors  for  improving 
readability  and  comprehensibility.  Three  systems  designed  originally  for 
examining  the  complexity  of  technical  documents  are  described.  These  are 
the  Bell  Laboratories  Writer’s  Workbench,  the  U.S.  Navy  Computer 
Readability  Editing  System,  and  the  Westinghouse  Writing  Aids  System. 
Though  in  varying  stages  of  development,  the  features  of  the  three 
systems  are  listed  and  compared  and  the  research  or  other  basis  behind 
the  editing  features  is  discussed.  Some  limited  data  on  the  use  of  the 
systems  and  their  acceptance  by  users  are  also  presented.  The  paper 
concludes  with  a  discussion  of  future  applications  of  the  systems  such  as 
writing  instruction,  style  comparison,  and  computer-aided  translation. 


1 .  INTRODUCTION 

For  thousands  of  years,  writing  and  editing  were  unmechanized  processes 
The  printing  press  and  the  typewriter  improved  the  legibility  of 

documents  but  were  of  little  help  in  the  creative  writing  process.  To 
produce  text  that  was  readable,  useable,  grammatically  correct,  well 
organized,  and  suitable  for  the  intended  audience,  writers  and  editors 
relied  on  a  variety  of  traditional  aids.  These  aids  included  personal 
knowledge,  dictionaries,  grammar  books,  and  style  guides.  Advice  was 

plentiful  but  often  hard  to  follow  consistently  because  of  deadlines, 

drudgery,  and  human  limitations.  In  this  century,  growth  in  the  economy, 
government,  and  technology  led  to  a  tremendous  increase  in  the  need  for 

documentation.  The  need  for  more  documentation  led  to  the  need  to 

automate  the  writing  process. 

Computer-based  word  processors  began  to  appear  in  the  early  1970's.  The 
first  word  processors  did  not  aid  the  creative  writing  process,  but  they 
helped  to  speed  up  the  production  of  documentation.  Once  text  was 
captured  in  machine-readable  form,  it  could  be  manipulated  in  many  ways. 
Writing  and  editing  changes  were  manually  marked  on  a  word  processor 
printout,  but  the  changes  could  then  be  keyboarded  for  automatic 
insertion  into  a  document.  Features  such  as  "global  search  and  replace" 
made  it  possible  to  make  numerous  corrections  in  a  single  operation.  The 
need  for  retyping  a  changed  manuscript  was  eliminated,  and  the  final 
version  of  a  document  could  be  reformatted  as  desired.  The  early  word 
processors  were  a  great  help  in  document  production,  but  more  automation 
was  needed. 

By  the  mid  1970' s,  researchers  began  to  realize  that  the  full 
computational  powers  of  word  processors  were  not  being  used.  For 
example,  if  a  unique  character  string  could  be  recognized,  why  not 
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recognize  all  unique  character  strings?  In  other  words,  why  not  program 
the  word  processor  to  check  spelling?  Similarly,  if  any  ASCII  character 
could  be  recognized,  why  not  use  this  power  to  count  words,  sentences, 
and  the  number  of  characters  or  syllables  in  a  word?  In  other  words, 
why  not  program  the  word  processor  to  calculate  the  readability  grade 
level  of  text? 

Programs  for  spelling  checks  and  readability  measurements  quickly  became 
the  first  automated  aids  to  the  creative  writing  processes.  The 
programs  were  faster  and  generally  more  accurate  than  humans;  they 
eliminated  a  great  deal  of  boredom  and  drudgery.  The  time  formerly  used 
to  check  spelling  could  be  devoted  to  other  efforts.  A  readability 
analysis  of  a  manuscript  helped  writers  and  editors  judge  its 
appropriateness  to  the  intended  audience.  The  success  of  spelling  check 
and  readability  programs  sparked  interest  in  developing  more  elaborate 
automated  aids  for  writers  and  editors. 

Independently  and  nearly  simultaneously,  researchers  at  Bell 
Laboratories,  the  U.S.  Navy's  Training  Analysis  and  Evaluation  Group 
(TAEG) ,  and  the  Integrated  Logistics  Support  Division  of  Westinghouse 
conceived  the  same  basic  idea.  Why  not  use  the  computer  or  word 
processor  to  automatically  analyze  text  for  compliance  with  clear 
writing  principles?  Automatic  text  analysis  could  provide  feedback  on 
writing  style,  style  difficulty,  vocabulary,  diction,  etc.  Text 
analysis  could  also  provide  suggestions  for  improving  the  grammar, 
punctuation,  readability,  and  comprehensibility  of  documents.  Freed  of 
many  time  consuming  and  tedious  manual  tasks,  writers  and  editors  could 
concentrate  on  other  considerations  in  document  design  such  as 
organization  and  content.  With  so  many  obvious  benefits  to  be  gained, 
research  on  automatic  text  analysis  began  in  earnest. 

The  early  research  at  Bell  Laboratories  was  directed  at  style  analysis 
and  identifying  faulty  diction;  TAEG  concentrated  first  on  style 
analysis  and  vocabulary  control;  and  Westinghouse  worked  first  on  style 
analysis  and  research-proven  suggestions  for  text  improvement.  The 
research,  though  not  complete,  has  led  to  the  development  of  Bell 
Laboratories'  Writer's  Workbench  programs,  TAEG’s  Computer  Readability 
Editing  System  (CRES) ,  and  Westinghouse’ s  Writing  Aids  System 
(WRITEAIDS ) .  (Other  organizations  including  IBM  and  The  University  of 
Michigan  are  also  working  on  automatic  text  analysis.) 

Section  2  of  this  paper  will  discuss  the  major  features  of  the  Writer's 
Workbench,  CRES,  and  WRITEAIDS  which  have  been  automated  or  are  under 
development.  Section  3  will  describe  the  feedback  provided  by  the 
systems.  Section  4  will  discuss  some  limited  data  on  user  acceptance. 
Section  5  will  address  future  applications  of  the  systems. 

2.  FEATURES  OF  THE  WRITER'S  WORKBENCH,  CRES,  AND  WRITEAIDS 

The  text  analysis  features  of  the  Writer's  Workbench,  CRES,  and 
WRITEAIDS  now  vary  considerably  even  though  the  ultimate  purpose  of  the 
systems  is  the  same.  However,  as  research  progresses,  the  three  systems 
are  becoming  more  and  more  similar.  The  Writer's  Workbench  programs  run 
under  the  UNIX*  operating  system.  Originally,  the  CRES  programs  were 

*UNIX  is  a  trademark  of  Bell  Laboratories. 


written  for  computers  or  word  processors  with  fairly  large  memory  capa- 
I  cities.  The  CRES  programs  are  now  being  rewritten  for  smaller 

stand-alone  word  processors.  The  WRITEAIDS  programs  were  designed  from 
the  start  for  small  stand-alone  word  processors. 

Text  analysis  features  tend  to  fall  into  three  main  categories  although 
there  is  clearly  some  overlap  in  the  categories.  In  the  first  category 
|  are  straightforward  features  which  are  loosely  defined  here  as  customs 

of  English  language  use.  The  second  category,  suggestions  from  writing 
experts,  includes  some  "grammar  rules"  and  clear  writing  principles. 
The  third  category,  suggestions  based  on  research,  includes  clear 
writing  principles  based  on  research  in  readability,  psychology, 
linguistics,  etc.  The  paragraphs  which  follow  discuss  the  similarities 
I  and  differences  among  the  three  systems  and  will  discuss  the  rationale 

for  the  features  where  appropriate. 

2 . 1  STRAIGHTFORWARD  FEATURES 

Table  1  summarizes  the  major  straighforward  features.  Bell  Laboratories 
I  has  implemented  all  of  the  features  in  this  category.  TAEG  and 

Westinghouse  have  not  yet  emphasized  research  in  this  area  to  any  great 
extent . 


TABLE  1.  STRAIGHTFORWARD  FEATURES 


Feature 

Writer*  s 
Workbench 

CRES 

WRITEAIDS 

1.  Spelling  Check 

Internally 

Developed 

Limited  to 
Master  Word 
List 

Commercial 

software 

2.  Punctuation  Check 

X 

Not  planned 

Not  planned 

3 .  Double  Word  Check 

X 

Not  planned 

Not  planned 

4.  Sexual  Bias 

About  170  words 
and  phrases 
mechanized 

Planned  for 

Mil-Spec 

compliance 

About  380 
words  mechan¬ 
ized  Mil-Spec 
compliance 

5.  Parts  of  Speech 
Analysis 

%  of  various 
type  of  words 
used 

Planned 

Not  planned 

6.  Sentence  Type 


It  of  various 
types  of 
sentences  used 


Planned 


Not  planned 


2.1.1  Spelling  Check 


The  Writer's  Workbench  spelling  check  program  has  an  internally  developed 
30,000  word  dictionary  with  affixes.3-  The  program  also  allows  users  to 
add  words  to  tailor  the  program  for  themselves.  Interactive  program 
features  allow  users  to  locate  possible  misspellings,  determine  correct 
spelling,  change  spelling  if  necessary,  and  add  words  to  a  personal 
dictionary 


CRES  provides  a  spelling  check  in  an  indirect  but  interesting  way.  Any 
word  that  is  not  on  the  Master  Word  List  is  flagged  as  an  uncommon 
word.3  The  flagged  words  are  thus  possible  misspellings. 


WRITEAIDS  uses  commercially  available  spelling  check  programs. 

2.1.2  Punctuation  Check 


A  Writer's  Workbench  program  searches  for  simple  punctuation  errors. 
When  this  program  finds  an  error  it  prints  the  original  line  and  a 
corrected  line.  It  recommends  changes  to  (1)  capitalize  the  first  letter 
of  a  sentence,  (2)  move  commas  and  periods  to  the  left  of  double  quotes 
and  move  semicolons  and  colons  to  the  right  of  double  quotes,  and  (3) 
balance  double  or  single  quotes  and  parenthesis.4 

Punctuation  checks  are  not  planned  for  CRES  or  WRITEAIDS. 

2.1.3  Double  Word  Check 


When  the  same  word  appears  twice  in  a  row,  a  Writer's  Workbench  program 
flags  the  double  entry  even  if  it  is  split  across  two  lines.  This  is  a 
difficult  error  for  humans  to  detect.2 

Double  word  checks  are  not  planned  for  CRES  or  WRITEAIDS. 

2.1.4  Sexist  Language 

The  Writer's  Workbench  has  a  program  that  identifies  terms  that  might 
suggest  sexual  bias  in  writing.2  The  program  contains  a  dictionary  of 
about  170  words  and  phrases  that  may  be  sexist. 

A  future  version  of  CRES  will  have  a  sexual  bias  program  that  complies 
with  military  specifications  for  technical  manuals. 

WRITEAIDS  has  a  program  that  checks  for  sexual  bias.  The  program 
contains  a  380  word  sexual  bias  dictionary. 

2.1.5  Parts  of  Speech  Analysis 

A  parts  of  speech  analysis  is  performed  by  a  set  of  Writer  s  Workbench 
programs.3  These  programs  use  a  small  dictionary,  suffix  rules,  and 
experimentally  derived  word  order  rules  to  assign  word  classes  to  all 
words  in  a  text.  The  analysis  is  about  95  percent  accurate.  One  purpose 
of  these  programs  is  to  provide  statistics  on  the  percentage  and  raw 
count  of  various  word  types  used  in  a  text.  These  programs  are  also  used 
with  several  other  Writer's  Workbench  programs  to  be  described  later. 


Parts  of  speech  identifiers  are  coded  with  the  entries  in  the  CRES 
Master  Word  List.  Plans  for  using  this  data  are  not  yet  complete.6 

Parts  of  speech  data  is  built  into  an  experimental  WRITEAIDS  program  for 
computer-aided  translation.  There  are  no  plans  to  use  such  data  for 
other  purposes. 

2.1.6  Sentence  Type  Analysis 

A  Writer's  Workbench  program  performs  a  sentence-type  analysis.  The 
program  determines  the  raw  count  and  percentage  of  simple,  complex, 
compound,  and  compound-complex  sentences  in  a  document.5 

A  sentence  type  analysis  feature  is  planned  for  CRES6  but  not  for 
WRITEAIDS . 

2.2  SUGGESTIONS  FROM  WRITING  EXPERTS 

Table  2  summarizes  automated  features  that  are  based  on  suggestions  from 
writing  experts  concerning  grammar  or  clear  writing  principles. 

2.2.1  Split  Infinitives  Check 

The  use  of  split  infinitives  is  often  considered  to  be  a  grammatical 
error.  Using  the  parts  of  speech  analysis  program  described  in 
Paragraph  2.1.5,  the  Writer's  Workbench  will  find  infinitives  that  are 
split  by  adverbs. ^  Users  can  obtain  printed  grammatical  information 
about  split  infinitives  from  another  program. 

A  split  infinitive  check  is  not  planned  for  CRES6  or  WRITEAIDS. 

2.2.2  "To  Be"  Check 

Some  writers,  including  Lanham,  suggest  that  document  revisors  should 
circle  all  forms  of  the  verb  "to  be"  and  try  to  replace  them.^ 
Following  this  advice  could  help  cut  down  on  the  use  of  passive  voice, 
nominalizations  (nouns  made  from  verbs),  and  expletives  (words  that  add 
no  information). 

A  Writer's  Workbench  program  underlines  and  capitalizes  all  forms  of  "to 
be".  The  text  printout  is  formatted  normally  so  potential  problems  are 
highlighted  in  context.  Bell  reports  that  this  is  a  useful  way  to  look 
at  the  first  draft  of  a  paper.4 

The  CRES  system  is  not  specifically  programmed  to  find  all  forms  of  "to 
be",  but  it  will  locate  full  passive  constructions.  A  "to  be”  check  is 
not  planned  for  WRITEAIDS. 

2.2.3  Preposition  Count 

The  excessive  use  of  prepositions  may  indicate  wordiness.  One  output  of 
the  Writer's  Workbench  parts  of  speech  analysis  is  a  preposition  count. 
This  data  is  probably  most  useful  when  included  in  a  style  comparison 
(refer  to  Paragraph  2.3.11). 
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TABLE 

1 

Feature 

2 .  SUGGESTIONS  FR( 

Writer’s 

Workbench 

~  ■  -V  ■ 

)M  WRITING  EXPER1 

CRES 

-  -  -  ^  ^ 

rs  _  \ 

WRITEAIDS 

1.  Split  Infinitive 
Check 

Flags  infinitives 
split  by  adverbs 

Not  planned 

Not  planned 

k  2.  "To  Be"  Check 

Flags  all  forms 
of  "to  be" 

Passives 

only 

Not  planned  * 

3.  Preposition 

Count 

i 

Included  in 
parts  of  speech 
analysis 

Identifies 
excessive  use 
of  preposi¬ 
tions  in  a 
sentence 

Not  planned 

-  *  •*  •'  4 

• 

4.  Wordiness/Phrase 
Substitution 

f 

About  400 

phrases 

mechanized 

About  250 

phrases 

mechanized 

About  400 
phrases 

mechanized  ‘ 

5.  Sentence  Opener 
Check 

X 

X 

Expletive  check 

Planned 

.  4 

^  6.  Clause  Length 

Check 

Not  Planned 

X 

Not  planned  ® 

7 .  Sentence  Type 
Variability 
ij  Check 

X 

Not  planned 

Not  planned 

8.  Paragraph  Length 
Check 

Not  planned 

X 

Planned 

9.  Organization 

L  Check 

X 

Not  planned 

Planned 

CRES  flags  sentences  containing  more  than  a  predetermined  number  or 
percentage  of  prepositions.®  A  preposition  count  is  not  planned  for 
WRITEAIDS . 

2. 2. A  Wordiness/Phrase  Substitution 

Writing  experts  have  identified  several  phrases  as  wordy,  awkward, 
repetitive,  or  frequently  misused.  Many  such  phrases  can  be  replaced 
with  a  single  word  or  a  shorter  phrase. 

The  Writer’s  Workbench  has  a  multi-purpose  dictionary  containing  about 
A00  wordy  or  frequently  misused  phrases.-*  String  matching  programs 
flag  the  faulty  phrases  and  suggest  one  or  more  substitutes.  The  writer 
or  editor  must  decide  if  a  suggested  substitute  is  appropriate  in  the 
context  in  which  it  would  be  used.  Users  can  tailor  the  dictionary  to 
their  own  needs  by  adding  or  deleting  terms. 
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CRES  also  has  a  multi-purpose  dictionary  containing  about  250  phrases 
with  as  many  as  two  suggested  substitutes  per  phrase. As  with  the 
Writer’s  Workbench,  CRES  users  must  decide  whether  suggested  substitutes 
are  appropriate.  CRES  users  can  tailor  the  phrase  dictionary  to  their 
own  needs . 

WRITEAIDS  has  a  dictionary  containing  about  400  phrases  with  one  or  more 
substitutes  per  phrase.9  The  purpose  and  use  of  this  dictionary  are 
virtually  identical  to  the  Writer's  Workbench  and  CRES. 

2.2.5  Sentence  Opener  Check 

Writing  experts  have  made  two  kinds  of  suggestions  about  sentence 
openers.  The  first  is  that  variety  in  sentence  openers  is  desirable. 
The  second  is  that  some  types  of  sentence  openers  are  wordy  or  should  be 
avoided  in  certain  instances.10 

Using  the  parts  of  speech  analysis  programs,  the  Writer's  Workbench 
provides  statistics  on  the  percentage  and  raw  count  of  the  types  of 
sentence  openers  used  in  a  text.5  With  experience  and  the  aid  of  an 
interpretive  program,  these  statistics  can  be  used  to  achieve  a  desirable 
variety  in  sentence  openers  and  to  avoid  the  excessive  use  of  undesirable 
sentence  openers  such  as  expletives. 

As  part  of  its  phrase  dictionary  software,  CRES  identifies  expletives. 
Another  CRES  program  advises  users  to  avoid  starting  sentences  with 
certain  subordinate  clauses.** 

The  only  sentence  opener  check  planned  for  WRITEAIDS  is  an  expletive 
check. 

2.2.6  Clause  Length/Awkwardness  Check 

Experts,  including  Klare,11  advise  that  clause  length  is  important 
apart  from  sentence  length.  They  suggest  reducing  clause  length  where 
possible . 

A  clause  length  check  is  not  planned  for  the  Writer's  Workbench.  CRES 
flags  clauses  with  more  than  10  words  and  flags  awkward  dependent 
clauses.8  A  clause  length  check  could  be  programmed  for  WRITEAIDS  but 
is  not  now  planned. 


2.2.7  Sentence  Type  Variability  Check 

Many  experts  agree  that  sentence  variety  adds  to  reading  pleasure  and  can 
help  hold  a  reader's  attention.11,1?  Some  writers  do  not  realize  that 
their  sentences  lack  variety.  Faced  with  stringent  format  and  style 
requirements,  they  may  find  it  difficult  to  consider  sentence  variability. 

Statistics  on  sentence  variety  are  provided  by  the  Writer's 
Workbench.5  Interpretive  programs  provide  writers  with  both  positive 
and  negative  variability  characteristics  of  their  text.  The  program 
provides  numerous  suggestions  for  increasing  sentence  variety.? 

Sentence  type  variability  checks  are  not  planned  for  CRES6  or  WRITEAIDS. 


2.2.8  Paragraph  Length  Check 


Long  paragraphs  can  be  hard  to  understand.  This  is  perhaps  because  the 
content  drifts  too  far  from  the  main  topic  or  because  the  writer  is 
poorly  organized.  A  long  paragraph  check  can  draw  attention  to 
paragraphs  that  may  need  to  be  rewritten. 

Paragraph  length  checks  are  not  planned  for  the  Writer’s  Workbench.  The 
CRES  system  flags  paragraphs  that  exceed  10  sentences.8  A  paragraph 
length  check  based  on  a  word  count  is  planned  for  WRITEAIDS . 

2.2.9  Organization  Check 

The  organization  of  a  document  provides  readers  with  useful  clues  that 
aid  understanding.  Until  the  1970's,  there  was  virtually  no  useful 
research  on  organization,  so  writers  relied  on  the  advice  of  experts. 

Those  experts  often  recommended  that  the  first  sentence  of  a  paragraph 
should  be  a  topic  sentence  or  should  serve  as  a  transition  from  the 
previous  paragraph  to  a  new  topic.  While  this  is  sound  advice, 
organization  is  related  to  content  in  other  complex  ways.  The  recent 
research  on  organization  is  still  quite  theoretical1^  and  can  not  yet 
be  automated.  Hopefully,  future  organization  suggestions  will  move  into 
the  category  of  suggestions  based  on  research. 

The  Writer's  Workbench  has  a  useful  program  to  help  writers  evaluate 
organization.  The  program  prints  paragraph  headings  and  preserves 
paragraph  boundaries,  but  it  prints  out  only  the  first  and  last  sentence 
of  each  paragraph.  This  printout  can  provide  an  abstract  of  a  paper  for 
writers  who  use  traditional  formats;  it  provides  a  structural  outline  for 
writers  with  a  more  casual  style.2 

There  are  no  plans  to  include  an  organizational  c.eck  in  the  CRES  system. 

In  1983,  research  on  the  practical  application  of  comprehension, 
coherence,  and  inference  loading  theories  will  begin  at  Westinghouse. 
The  long  range  goal  is  to  implement  research-based  organizational  checks 
in  the  WRITEAIDS  system. 

2.3  SUGGESTIONS  BASED  ON  RESEARCH 

In  this  category,  the  similarities  of  the  three  systems  are  pronounced. 
The  differences  between  the  systems  tend  to  reflect  either  the 
organizational  goals  of  Bell  Laboratories,  TAEG ,  or  Westinghouse  or  the 
areas  of  most  interest  to  the  various  researchers.  There  is  no  doubt 
that  the  three  organizations  are  working  with  the  same  basic  ideas  and 
data.  Differences  in  available  hardware  and  software  have  led  to  some  of 
the  different  approaches  for  applying  the  suggestions  based  on  research. 
Table  3  summarizes  automatic  features  based  on  research  in  readability, 
comprehensibility,  psychology,  linguistics,  and  psycholinguistics. 


Feature 

Writer' s 
Workbench 

CRES 

WRITEAIDS 

1.  Readability 
Analysis 

Flesch,  Flesch- 
Kin.  ARI,  Col- 
Liau 

Flesch , 
Flesch-Kin . 

Flesch, 
Flesch-Kin . 

2.  Test  Q  Analysis 

Not  Planned 

Readability, 

item 

construction 

Not  planned 

3.  Readability  Sum. 

X 

Meets 

Mil-spec 

Meets 

Mil-spec 

4.  Vocabulary 

Check 

Not  planned 

4300  root 
words,  plus 
supplements 

Two  vocabs. 
planned 

5 .  Word 

Substitution 

100  root  words, 
less  awkward 
substitutes 

250  root  words, 
substitutes 
based  on 
length 

1000  root  words , 
substitutes 
based  on  length, 
f am. ,  f req . 

6.  Abstract  Word 

Check 

Nouns,  verbs, 
adjs . 

Planned 

Nouns-verbs , 
adjs. 

7.  Nominalization 
Check 

X 

X 

Exception 

List 

8.  Long  Sen.  Ck. 

X 

X 

X 

9.  Neg.  Statement 
Check 

Not  planned 

Double  negs . 
text  -  all 
negs.  tests 

Direct  negs. 

10.  Passive  Check 

X 

Full  passives 

X 

11.  Style  Comparator 

X 

Not  planned 

Future 

2.3.1  Readability  Analysis 

The  term  readability  analysis,  as  applied  here,  refers  to  predicting  the 
style  difficulty  of  text  by  readability  formula.  Readability  formulas 
can  be  misused  because  they  are  not  intended  to  measure  content, 
organization,  format,  legibility,  or  other  factors  considered  important 
to  comprehension.  Laymen  often  drop  the  word  "readability"  from  formula 
score  descriptions  and  thus  tend  to  equate  the  scores  with  age  groups  or 
conceptual  difficulty,  neither  of  which  is  correct. 
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When  the  data  from  a  readability  analysis  is  properly  applied,  it  can 
provide  valuable  insight  into  potential  problems  with  word  use,  sentence 
use,  or  both.  When  a  thoughtful  sampling  procedure  is  used,  a 
readability  analysis  will  also  highlight  the  particular  portions  of  a 
document  that  are  most  likely  to  need  revision.  While  perhaps  hundreds 
of  readability  formulas  exist,  all  three  organizations  agree  that  the 
Flesch-Kincaid  formula  seems  to  be  the  most  appropriate  formula  for 
technical  material.5'®*14 

The  Writer's  Workbench  calculates  four  readability  indices:  The  Flesch 
Reading  Ease  Score15,  The  Flesch-Kincaid  Formula16,  The  Automated 
Readability  Index17,  and  The  Coleman-Liau  Formula1®.  One  program 
prints  the  four  formula  scores  and  provides  statistics  on  the  average 
word  and  sentence  length.  Another  program  interprets  the  Flesch-Kincaid 
score  for  users.2 

CRES  calulates  the  Flesch  Reading  Ease  Score  and  the  Flesch-Kincaid 
Formula.  The  CRES  readability  analysis  provides  statistics  on  the 
average  number  of  words  per  sentence  and  the  average  number  of  syllables 
per  word.  It  also  lists  the  words  in  a  text  which  do  not  appear  on  the 
Master  Word  List  (refer  to  Paragraph  2.3.4). 

WRITEAIDS  also  calculates  the  Flesch  Reading  Ease  Score  and  the 
Flesch-Kincaid  Formula.  The  WRITEAIDS  readability  analysis  provides  raw 
data  and  the  same  statistical  data  as  CRES.  WRITEAIDS  also  lists  words 
of  three  or  more  syllables  in  the  order  that  the  words  appeared  in  the 
analyzed  text . 

2.3.2  Test  Question  Analysis 

Research  has  identified  numerous  principles  for  constructing  good 
true-false  and  multiple-choice  test  questions.  For  a  summary  of  that 
research,  see  Kincaid,  Braby,  and  Wulfeck.19  TAEG  has  a  specific  need 
for  test  question  analysis  so  CRES  is  the  only  one  of  the  three  systems 
that  automates  this  feature. 

The  CRES  test  question  analysis  includes  all  of  the  regular  features  of 
CRES  plus  several  features  specified  by  the  Navy's  Instructional  Quality 
Inventory20  (IQI).  IQI  features  for  multiple-choice  questions  include 
flagging  long  sentences,  inappropriate  answers,  the  fact  that  the  longest 
answer  is  correct,  and  repetitive  words  and  phrases.  IQI  features  for 
true-false  questions  include  flagging  long  questions,  negative  wording, 
and  complex  questions.1^ 

2.3.3  Readability  Summary  of  Several  Passages 

A  readability  summary  of  the  analysis  of  several  passages  from  the  same 
document  helps  writers  identify  specific  types  of  writing  or  specific 
parts  of  a  document  that  are  most  likely  to  need  revision. 

Interpretive  programs  in  the  Writer's  Workbench  provide  both  tabular  and 
written  summaries  of  the  scores  for  individual  passages.  Users  can 
compare  the  summaries  for  the  individual  passages.  These  programs  alro 
provide  written  information  on  the  background  that  readers  might  need  to 
understand  the  document.2 


Both  CRES6  and  WRITEAIDS  provide  readability  summaries  that  permit  a 
side-by-side  comparison  of  the  passages  within  a  document.  These 
summaries  include  the  raw  data,  index  variables,  and  readability  scores 
for  individual  passages.  Both  systems  also  provide  an  overall 
readability  analysis  of  an  entire  document  that  complies  with  military 
specification  requirements. 

2.3.4  Controlled  Vocabulary  Check 

Studies  show  that  when  the  words  used  in  written  materials  are  familiar 
to  intended  readers  the  materials  are  easier  to  read  and  understand. 
Several  researchers  have  prepared  "controlled  vocabularies"  which  permit 
the  use  of  only  those  terms  that  are  either  known  to  be  familiar  or  will 
be  taught  to  intended  readers.  Many  "controlled  vocabularies",  ranging 
in  length  from  about  1000  to  4000  root  words,  have  been  prepared  for 
technical  materials.  Two  types  of  "controlled  vocabularies"  have 
emerged.  The  first  type  is  based  on  word  frequency  analysis  and  permits 
multiple  meanings  of  the  same  word.  The  second  type  is  based  on  the  one 
word-one  meaning  concept  and  permits  only  one  shade  of  meaning  for  a  word. 

There  are  no  plans  to  include  a  controlled  vocabulary  in  the  Writer’s 
Workbench . 

CRES  has  a  controlled  vocabulary  called  the  Master  Word  List.  This  list 
is  based  on  (1)  word  frequency  analysis  of  Navy  training  materials,  and 
(2)  word  lists  prepared  by  several  military  and  nonmilitary  organiza¬ 
tions. 3  The  Master  Word  list  consists  of  about  4300  root  words  plus 
all  inflected  forms  of  the  root  words.  The  Master  Word  List  can  be 
tailored  to  specific  audiences  by  adding  supplementary  technical  terms 
that  are  peculiar  to  special  disciplines.  CRES  flags  all  words  in  a  text 
that  do  not  appear  on  the  Master  Word  List.  A  writer  or  editor  replaces 
flagged  words  with  common  words  where  possible. 

Two  "controlled  vocabularies"  are  planned  for  WRITEAIDS.  The  plans  are 
to  add  the  CRES  word  lists  and  an  internally  developed  one  word- one 
meaning  logistics  glossary. 

2.3.5  Word  Substitution 

Readability  research  has  shown  that  a  reader’s  speed,  recall,  and 
comprehension  can  often  be  improved  if  the  difficult  content  words  of  a 
passage  are  changed  in  certain  ways.  Words  that  are  shorter,  more 
frequently  used,  or  more  familiar  tend  to  improve  human  performance  in 
reading.  See  Klare11  for  an  extensive  discussion  of  the  literature. 
Word  substitution  dictionaries  are  designed  to  suggest  simpler 
alternatives  for  the  difficult  nontechnical  words  that  appear  in  a 
passage.  Before  using  a  suggested  substitute,  the  writer  or  editor  must 
make  sure  that  the  meaning  of  the  text  will  not  be  changed. 

The  same  Writer's  Workbench  dictionary  that  lists  awkward  or  misused 
phrases  also  contains  about  100  words  that  are  potentially  awkward.  A 
string  matching  program  flags  the  difficult  words  when  they  occur  in  a 
passage.  Users  can  request  a  printout  that  suggests  one  or  more  shorter 
substitutes  for  the  flagged  words.  Users  can  also  tailor  the  dictionary 
to  their  own  needs  by  adding  or  deleting  terms. * 


The  CRES  word  substitution  dictionary  contains  about  250  potentially 
difficult  root  words.6  CRES  automatically  flags  each  word  in  a  passage 
that  matches  a  word  in  the  dictionary  and  prints  out  up  to  two  suggested 
substitutes . ^  Terms  can  be  added  to  or  deleted  from  the  dictionary. ° 

The  WRITEAIDS  substitution  dictionary  contains  about  1000  potentially 
difficult  words.  WRITEAIDS  automatically  flags  each  word  in  a  passage 
that  matches  a  word  in  the  dictionary  and  prints  out  all  available 
suggested  substitutes.  The  dictionary  was  specially  constructed  to 
suggest  changes  based  on  readability  research.  With  a  few  minor 
exceptions,  each  suggested  substitute  is  a  shorter  word,  a  more  familiar 
word21,  and  a  more  frequently  used  word.22  when  all  appropriate  word 
changes  are  inserted,  the  readability  grade  level  of  a  document  is 
automatically  lowered;  the  probability  is  that  the  comprehensibility  of 
the  document  is  also  improved. 

2.3.6  Abstract  Word  Check 

Concrete  words,  which  easily  arouse  an  image  in  one's  mind,  contribute 
more  to  readable  writing  than  abstract  words.  Studies  have  shown  that 
concreteness  can  improve  human  performance  scores  in  recognition  and 
recall  memory,  readability  judgements,  sentence  usage,  information  gain, 
and  recognition  time.  See  Klare11  for  a  summary  of  the  literature. 

The  conceptual  abstractness  of  text  is  checked  by  a  Writer's  Workbench 
program.  The  program  calculates  the  percentage  of  words  in  a  text  that 
appear  on  a  list  of  314  abstract  nouns,  verbs  and  adjectives  compiled 
through  psychological  research.  When  the  percentage  of  abstract  words 
exceeds  2.3  percent,  the  program  suggests  that  concrete  examples  should 
be  used  to  clarify  the  text.*1 

An  abstract  word  check  is  planned  for  CRES. 

WRITEAIDS  contains  a  list  of  about  275  abstract  nouns,  verbs,  and 
adjectives.  A  string  matching  program  flags  each  word  in  the  text  that 
occurs  on  the  abstract  word  list.  A  user's  manual  suggests  that  concrete 
examples  should  be  used  to  clarify  the  text.23 

2.3.7  Nominalization  Check 

Excessive  use  of  nominalizations  (nouns  made  from  verbs)  tends  to  make 
text  less  readable.  Studies  have  shown  that  replacing  nominalizations 
with  the  active  verb  form  can  improve  human  performance  scores  in 
comprehension,  recall,  and  information  gain.  See  (Clare*1  for  a  summary 
of  the  literature. 

The  Writer's  Workbench  program  for  parts  of  speech  analysis  identifies 
nominalizations.  Another  program  calculates  the  raw  count  and  percentage 
of  nominalizations  in  the  text.  An  interpretive  program  advises  writers 
to  avoid  excessive  nominalizations  by  transforming  nominalized  sentences 
to  the  active  verb  form.2 

A  nominalization  check  is  available  for  CRES.6 


The  WRITEAIDS  nominalization  check  is  based  on  the  same  string  matching 
techniques  used  in  the  Writer's  Workbench.  A  special  exception 
dictionary  is  used  to  avoid  flagging  words  which  are  actually  verbs  or 
are  both  nouns  and  verbs.  The  program  flags  each  nominalization  that 
occurs  in  a  passage.  A  user's  manual  advises  writers  to  transform 
nominalizations  to  the  active  verb  form  where  possible. 23 

2.3.8  Long  Sentence  Check 

Shortened  sentences  contribute  to  more  readable  writing.  Research  shows 
that  certain  sentence  changes  improve  human  performance  in  reading 
comprehension  and  speed.  See  Klare11  for  a  discussion  of  the 
literature . 

A  Writer's  Workbench  program  determines  the  percentage  of  short  and  long 
sentences  and  the  length  and  location  of  the  shortest  and  longest 
sentences  in  a  passage.5  Another  program  allows  users  to  locate  all 
sentences  that  exceed  a  specified  number  of  words  or  contain  less  than  a 
specified  number  of  words. 

The  long  sentence  checks  in  ORES  and  WRITEAIDS  are  virtually  identical. 
Both  systems  automatically  flag  the  end  of  each  sentence  that  exceeds  a 
specified  number  of  words. 

2.3.9  Negative  Statement  Check 

Negative  statements  sometimes  require  more  time  or  cause  more  errors  in 
verifying  truth  or  falsity  than  affirmative  statements.11  Many 
negative  statements  can  be  transformed  into  affirmative  statements. 

A  negative  statement  check  is  not  planned  for  the  Writer's  Workbench. 

CRES  offers  two  types  of  negative  statement  checks.  For  normal  text, 
CRES  flags  each  sentence  containing  a  double  negative.  When  used  to 
check  true-false  or  multiple-choice  test  questions,  CRES  flags  any 
negative  construction. 

WRITEAIDS  flags  all  occurrences  of  the  direct  negatives  no,  not,  or  nor. 
Numerous  additional  forms  of  negative  constructions  have  been  identified 
but  have  not  yet  been  programmed.  A  user's  manual  asks  writers  to 
transform  negative  statements  to  positive  statements  where  possible.23 

2.3.10  Passive  Voice  Check 

The  excessive  use  of  passive  sentences  is  one  of  the  biggest  problems  in 
technical  writing.  Sentences  written  in  passive  voice  tend  to  be  longer, 
less  direct,  and  less  vigorous  than  sentences  written  in  active 
voice. 2^  Changing  sentences  from  passive  voice  to  active  voice  can 
improve  a  reader’s  verification  and  recall.11  However,  passives  are 
often  needed  to  add  variety,  emphasize  the  object  of  the  sentence,  or 
avoid  naming  an  unknown  or  unimportant  actor. 

The  Writer's  Workbench  calculates  the  percentage  of  passives  used  and 
will  locate  passive  constructions  on  request.  An  interpretive  program 
advises  users  on  how  to  revise  sentences  to  avoid  the  excessive  use  of 
passive  voice.2*5 
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The  ORES  system  flags  each  passive  sentence  that  can  be  transformed  to 
active  voice.®  CRES,  therefore,  avoids  flagging  truncated  passives 
which  are  often  impossible  to  transform. 

WRITEAIDS  identifies  each  passive  sentence  that  occurs  in  a  passage.  A 
user's  manual  advises  writers  to  transform  sentences  from  passive  voice 
to  active  voice  where  possible. 

2.3.11  Style  Comparator 

A  style  comparator  not  only  provides  style  statistics  but  it  also 
interprets  the  statistics.  This  feature  compares  the  style  of  a  new  text 
against  a  set  of  style  standards  and  describes  the  differences. 

Bell  Laboratories  has  prepared  several  sets  of  style  standards  for 
various  types  of  documents.  The  style  standards  reflect  the  writing  from 
a  collection  of  documents  of  each  type,  which  were  judged  to  be  good.^ 

A  Writer’s  Workbench  user  selects  which  set  of  built-in  standards  should 
be  used  to  interpret  a  new  document.  Users  can  also  tailor  standards  for 
a  particular  audience  by  creating  new  standards  from  a  set  of  documents. 
The  Writer's  Workbench  style  comparator  identifies  those  style  values  of 
a  new  document  which  are  outside  the  range  of  the  selected  standard.  A 
two-to-three  page  output  in  written  English  explains  why  deviations  from 
the  standards  may  make  the  new  document  hard  to  understand.  The  same 
output  explains  how  to  rewrite  the  text  to  remove  problems.  Users 
receive  positive  feedback  when  style  values  meet  the  built-in 
standards .* 

A  style  comparator  is  not  planned  for  CRES.®  Funding  for  development 
of  a  WRITEAIDS  style  comparator  has  been  requested. 

3.  FEEDBACK  PROVIDED  BY  THE  SYSTEMS 

The  word  feedback,  as  used  in  this  section,  refers  to  the  information 
supplied  by  the  systems  to  the  users.  All  of  the  systems  allow  users  to 
select  various  program  options  from  a  menu;  in  some  instances  there  are 
both  short  and  long  versions  of  the  same  option.  The  systems  provide 
feedback  on  either  a  hard  copy  printout  or  a  CRT  display.  This  paper 
will  only  describe  feedback  from  hard  copy  printouts. 

To  obtain  data  for  this  section,  ten  samples  of  text  were  analyzed  by 
each  of  the  three  systems.  Space  does  not  permit  showing  all  of  the  data 
(over  150  pages).  However,  the  Appendix  contains  all  of  the  printouts 
provided  by  each  system  for  one  of  the  ten  samples.  These  printouts 
provide  representative  examples  of  many  of  the  text  analysis  features 
described  in  Section  2.  Differences  between  the  comparable  features  of 
the  three  systems  reflect  differences  in  the  algorithms,  word  lists,  and 
program  formats . 

3.1  WRITER'S  WORKBENCH 

The  feedback  provided  by  the  Writer's  Workbench  can  be  grouped  into  three 
categories.  Those  categories  are  described  as  statistical  analysis, 
objective  analysis,  and  interpretive  analysis.  The  Appendix  shows  the 
Writer's  Workbench  printouts  in  the  order  in  which  they  are  discussed. 
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3.1.1  Statistical  Analysis 

The  Writer's  Workbench  provides  statistical  feedback  on  a  wide  range  of 
style  variables.  For  a  given  document,  the  variables  reported  include 
readability  indexes,  information  on  average  word  and  sentence  lengths, 
the  distribution  of  sentence  lengths  and  types,  the  usage  of  various 
parts  of  speech,  and  the  distribution  of  sentence  openers.  The  data 
includes  both  raw  counts  and  percentages.  Standing  alone,  the  output  of 
the  program  that  compiles  statistical  data  is  most  useful  for  research  on 
the  style  of  documents.  However,  the  output  of  the  program  is  also  used 
as  the  input  for  the  interpretive  analysis  described  in  Paragraph  3.1.3. 

3.1.2  Objective  Analysis 

The  Writer's  Workbench  performs  several  tedious  and  unrewarding  tasks 
that  were  traditionally  done  by  writers  and  editors.  Proofreading 
programs  check  for  problems  which  are  objective  in  nature  such  as 
spelling,  punctuation,  grammar,  and  sexual  bias.  An  organization  program 
provides  a  look  at  the  overall  structure  of  a  document. 

Feedback  from  the  proofreading  analysis  is  provided  by  English  language 
printouts.  The  printouts  first  describe  the  type  of  check  performed 
(spelling,  punctuation,  double  word  entry,  word  choice,  split 
infinitives,  or  sexist  language).  Next,  the  printouts  identify  each 
possible  error  found;  if  no  error  is  found,  a  brief  statement  to  that 
effect  is  printed  out.  Finally,  for  each  possible  error  detected,  the 
printout  lists  suggested  corrections  or  revisions.  The  decision  to 
accept  or  reject  the  suggestions  is  left  to  the  user. 

The  organization  program  preserves  the  headings  and  paragraph  boundaries 
of  the  text,  but  it  prints  out  only  the  first  and  last  sentence  of  each 
paragraph.  The  actual  evaluation  of  the  text  structure  is  left  to  the 
user . 


3.1.3  Interpretive  Analysis 

The  output  from  programs  for  statistical  style  analysis  is  used  as  the 
input  for  interpretive  programs  available  on  the  Writer’s  Workbench.  The 
interpretive  programs  provide  users  with  positive  and  negative  feedback 
in  one  of  two  forms.  The  longer  form  provides  a  written  report  that 
discusses  in  prose  how  the  input  text  compares  with  a  set  of  built-in 
standards.  The  short  form  compares  the  input  text  with  the  same 
standards  but  prints  out  only  brief  comments. 

For  short  documents,  the  long  form  starts  with  a  one  sentence  warning 
that  the  interpretive  analysis  may  be  misleading.  A  one  sentence  note 
then  informs  the  user  of  the  standards  being  used  to  judge  the  input 
text.  Next,  the  printout  provides  a  written  comparison  of  the  style 
variables  of  the  input  text  with  the  built-in  standards.  If  a  particular 
style  variable  meets  the  standard,  a  short  statement  to  that  effect  is 
printed  out.  If  a  variable  (readability  for  example)  exceeds  the 
standard,  the  user  is  provided  with  a  longer  report  containing  remedial 
information.  That  information  describes  the  problems  that  readers  may 
encounter  because  the  standard  was  exceeded,  some  reasons  why  the 
standard  was  exceeded,  and  practical  suggestions  for  improving  the  text. 
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The  short  form  of  the  interpretive  analysis  also  starts  with  a  warning 
(for  short  documents)  that  the  analysis  may  be  misleading.  It  then  lists 
the  style  variables  analyzed  and  simply  states  whether  the  score  for  each 
variable  is  good  or  high.  If  the  score  is  high,  the  printout  suggests 
what  a  good  score  would  be  and  perhaps  a  brief  suggestion  for 
improvement . 

3 . 2  CRES 

CRES  provides  two  types  of  feedback.  The  first  is  a  statistical  analysis 
and  the  second  is  an  "in  context”  analysis.  The  Appendix  shows  both 
types  of  feedback. 

3.2.1  Statistical  Analysis 

CRES  provides  statistical  feedback  on  readability  and  word  usage  for  a 
particular  document.  A  printout  shows  the  raw  count  of  sentences,  words, 
and  syllables,  information  on  average  word  and  sentence  lengths, 
readability  indexes,  and  an  alphabetical  listing  of  uncommon  words.  This 
type  of  feedback  is  useful  for  evaluating  compliance  with  requirement 
specifications  and  highlighting  potential  areas  of  style  difficulty. 

3.2.2  "In  Context”  Analysis 

CRES  provides  feedback  on  style  analysis  by  directly  flagging  potential 
problems  in  the  context  in  which  they  actually  occur.  Potential  problems 
with  particular  words  or  phrases  are  flagged  by  bracketing  the  actual 
word  or  phrase  with  a  set  of  symbols.  Uncommon  words  are  bracketed  by 
the  symbols  ”[  ]”.  Words  or  phrases  for  which  there  are  suggested 
substitutes  are  bracketed  by  the  symbols  ”  suggested  substitutes  are 
inserted  immediately  after  flagged  items  using  the  same  set  of  symbols. 
The  number  of  words  in  a  long  sentence  is  printed  out  within  the  ”  ” 
symbols  after  the  sentence  identifying  punctuation.  All  comments  about 
style  are  made  within  the  ”  ”  symbols  as  potential  problems  occur 
anywhere  in  the  text.  A  CRES  user's  manual  explains  the  meaning  of  the 
symbols  and  provides  practical  advice  for  improving  text  in  response  to 
the  flagged  problems. 

3 . 3  WRITEAIDS 

WRITEAIDS  also  provides  two  types  of  feedback.  Like  CRES,  the  first  is  a 
statistical  analysis  and  the  second  is  an  ”in  context”  analysis.  The 
Appendix  shows  both  types  of  feedback. 

3.3.1  Statistical  Analysis 

WRITEAIDS  provides  statistical  feedback  on  the  readability  of  a 
document.  A  printout  shows  the  raw  count  of  sentences,  words  and 
syllables,  information  on  average  word  and  sentence  lengths,  and 
readability  indices.  The  same  printout  also  lists  the  long  words  in  the 
order  in  which  they  occur  in  the  document.  Readability  statistics  and 
long  word  lists  are  useful  for  evaluating  compliance  with  requirement 
specifications  and  highlighting  potential  areas  of  style  difficulty. 


3.3.2  "In  Context”  Analysis 

Like  CRES ,  WRITEAIDS  provides  feedback  on  style  analysis  by  identifying 
potential  problems  in  context.  Unlike  CRES,  comments  and  suggested 
changes  are  made  below  each  line  of  text  instead  of  being  interspersed  in 
the  text.  Two  different  types  of  printouts  are  used  to  provide  "in 
context"  feedback. 

One  printout  shows  suggestions  for  word  substitution  and  identifies  long 
sentences.  This  printout  shows  each  line  of  text  exactly  as  it  appears 
in  the  document  being  analyzed.  Below  each  line  of  text  is  a  list  of  the 
words  for  which  there  are  suggested  substitutes;  all  available  suggested 
substitutes  are  printed  out  immediately  after  each  listed  word.  If  a 
line  of  text  includes  the  end  of  a  long  sentence,  a  "long  sentence"  note 
is  printed  out  below  the  line.  Users  can  mark  accepted  word  and  sentence 
changes  directly  on  this  printout.  The  printout  showing  suggestions  for 
phrase  substitution  is  similar  to  the  word  substitution  printout,  but  it 
does  not  identify  long  sentences. 

The  program  that  produces  the  printout  described  in  the  preceding 
paragraph  also  creates  a  special  file  (stripped  of  punctuation)  used  in 
other  style  analysis  checks.  This  file  is  printed  out  double  spaced. 
The  blank  lines  below  each  line  of  text  contain  flags  that  identify 
potential  style  problems.  For  example,  the  flag  NOM  appears  directly 
beneath  each  nominalization .  Multiple  flags  can  be  printed  out  for  the 
same  word.  A  user’s  manual  explains  the  flags  and  makes  practical 
suggestions  for  improving  the  text. 

4.  USER  ACCEPTANCE 

Because  large  scale  tests  of  user  acceptance  began  only  recently,  there 
is  very  little  hard  data  to  report  on  this  topic.  However,  users  in 
general  report  that  the  systems  are  useful,  serve  their  intended  purpose, 
improve  the  quality  of  final  documents,  and  may  improve  the  skills  of 
writers  and  editors.  Users  also  seem  to  appreciate  the  impersonal  nature 
of  the  suggestions  made  by  the  systems. 

4.1  WRITER’S  WORKBENCH 

One  survey  of  Writer’s  Workbench  users  found  that  most  think  the  feedback 
from  the  system  is  clear,  and  the  system  is  likely  to  find  things  the 
user  would  miss.  A  significant  number  of  users  reported  that  the  system 
improves  their  writing  skills.  Other  trials  have  shown  that  under  time 
pressure,  technical  writers  detected  significantly  more  planted  errors 
with  the  system  than  without  it.2 

4 . 2  CRES 

CRES  has  been  used  by  two  large  defense  contractors  to  edit  technical 
manuals.  Users  report  that  the  use  of  CRES  results  in  improved 
documentation  with  about  a  SO  percent  savings  in  editing  time.6 

4 . 3  WRITEAIDS 

Experiments  using  WRITEAIDS  to  edit  technical  manuals  began  in  September 
1982,  so  only  the  general  comments  made  in  Paragraph  4  can  be  made. 
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5.  FUTURE  APPLICATIONS 

Computer-aided  editing  systems  already  provide  a  wealth  of  information 
and  numerous  ways  to  apply  that  information.  Future  applications  or 
adaptations  of  the  systems  seem  to  be  limited  only  by  Imagination.  Some 
future  uses  seem  obvious  once  they  are  stated;  others  require  insight 
into  the  problems  faced  by  readers,  writers,  and  editors.  The  closing 
paragraphs  of  this  paper  will  explore,  without  elaboration,  a  wide  range 
of  possible  applications. 

5 . 1  ADDITIONAL  FEATURES 

Research  on  reading  and  writing  has  provided  some  suggestions  for 
improving  text  that  have  not  yet  been  automated.  Some  of  these 
suggestions  that  could  be  additional  features  include: 

(1)  a  check  for  references  back  to  earlier  parts  of  a  text  (anaphora), 

(2)  a  check  for  references  forward  to  later  parts  of  a  text  (cataphora), 

(3)  a  word  association  check, 

(4)  a  word  depth  check,  and 

(5)  a  self-embedded  statement  check. 

Future  research  on  reading  and  writing  may  provide  additional  text 
analysis  features.  Some  possible  features  are: 

(1)  an  index  of  conceptual  difficulty, 

(2)  a  check  on  the  coherence  of  a  document,  and 

(3)  a  measure  or  check  of  organization. 

Additional  objective  features  that  could  save  production  time  are: 

(1)  automatic  generation  of  an  index,  and 

(2)  automatic  generation  of  a  table  of  contents  (this  feature  is 
available  at  Bell  Laboratories) 

5.2  ADAPTATION  TO  OTHER  USES 

With  little  or  no  further  development,  computer-aided  editing  can  be 
adapted  to  other  uses.  Possible  adaptations  include: 

(1)  editing  the  data  base  used  in  computer-aided  authoring  systems, 

(2)  using  the  text  analysis  features  to  help  writing  students  analyze 
their  own  texts  (experiments  using  the  Writer's  Workbench  are  being 
performed) , 

(3)  using  style  comparators  to  help  students  compare  their  writing  with 
that  of  famous  writers  or  with  standards, 

(4)  using  style  comparators  to  smooth  out  differences  in  style  between 
multiple  contributors  to  the  same  document,  and 

(5)  using  text  analysis  to  help  instructors  diagnose  problems  in 
students'  writing. 

With  further  development,  software  techniques  for  editing  could  be 
combined  with  software  for  other  applications  to  help  solve  problems  in 
other  areas.  For  example: 
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(1)  editing  software  could  be  combined  with  software  that  divides 
sentences  at  pausal  boundaries  to  prepare  more  understandable  CRT 
messages  (this  would  be  especially  useful  for  preparing  emergency 
operating  procedures),  and 

(2)  software  for  parts  of  speech  analysis,  word  substitution,  and  phrase 
substitution  could  be  combined  with  software  for, syntax  conversion  to 
prepare  fairly  high  quality  translations  from  English  to  other 
languages . 
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Aug  24  13:05  1982  THIS  IS  THE  STYLE  TABLE  POR  kniffinOS  Rag*  1 


readability  grades: 

(Kincaid)  16.2  (auto)  16.5  (Coleaan-Llau)  15.2  (Pleach)  17. 
sentence  info: 

no.  sent  19  no.  wds  463 
av  sent  long  24.4  av  word  long  5.48 
no.  questions  0  no.  imperatives  0 
no.  content  wds  232  55.64  av  leng  7.56 

short  sent  ( <1 9 )  16%  (3)  long  sent  (>34)  11%  (2) 

longest  sent  37  wds  at  sent  2)  shortest  sent  6  wds  at  sent  6 
sentence  types: 

simple  26%  (5)  complex  47%  (9) 
compound  11%  (2)  compound-complex  lfi%  (3) 
word  usage: 

vero  types  as  %  of  total  verbs 
cobe  30%  (16)  aux  21%  (11)  inf  26%  (14) 
passives  as  %  of  non- inf  verbs  13%  (5) 
types  as  %  of  total 

prep  12.3%  (57)  conj  1.9%  (9)  adv  3.7%  (17) 
noun  26.3%  (122)  adj  16.8%  (78)  pron  3.9%  (18) 
nominalizations  4  %  (20) 
sentence  beginnings: 

subject  opener:  noun  (0)  pron  (1)  pos  (0)  adj  (4)  art  (4)  tot 
prep  16%  (3)  adv  26%  (5) 

verb  0%  (0)  sub  conj  11%  (2)  conj  0%  (0) 
expletives  0%  (0T 


(22.2) 
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Aug  24  13:01  1982  PROOFR  OUTPUT  FOR  kniffinOS  Pag*  1 


.A****************************  SPELLING  ************* 

Possible  spalling  errors  in  kniffinOS  are: 

anaphora 

If  any  of  these  words  are  spelled  correctly,  later  type 
spelladd  wordl  word2  ...  wordn 
to  have  then  added  to  your  spelldict  file. 


*»o**to****t*«o»****t****»  PUNCTUATION  ************ 

The  punctuation  in  kniffinOS  is  first  described. 

4  double  quotes  and  0  single  quotas 
1  apostrophes 

0  left  parentheses  and  0  right  ones 

The  program  next  prints  any  sentence  that  It  thinks  is 
incorrectly  punctuated  and  follows  it  by  its  correction. 


No  errors  found  in  kniffin06 


*****************************  DOUBLE  WORDS 
For  file  knif f in06: 

No  double  words  found. 


ft****************************  WORD  CHOICE  ******************** 

Sentences  with  possibly  wordy  or  misused  phrases  are  listed  next 
followed  by  suggested  revisions. 


For  file  kniffinOS 
beginning  line  1  kniffin06 

Because  our  *(  endeavor] *s  to  ameliorate  readability  and  text 
processing  are  familiar  at  numerous  echelons  of  the  military, 
the  requirement  for  an  alteration  in  our  standard  demonstration 
therefore  became  obvious. 

beginning  line  9  kniffin06 

Accordingly,  you  are  observing  an  amalgamation  of  the  products 
of  our  ongoing  and  future  research  with  our  objective  being  to 
exhibit  a  consolidated  demonstration  of  our  efforts  at  producing 
beneficial  *(  modification] *s  in  both  text  and  text  processing. 

beginning  line  14  kniffin06 
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w*  *t  anticipate] *  that  *[  aubaaquant] *  to  th*  termination  of 
this  demonstration,  th*  huaan  propensity  to  forget  all  th*  technicallti 
will  talc*  affect;  however,  by  retaining  th*  saapl*  transcriptions 
provided  to  you,  you  can  *(  facilitat] *e  your  memory. 

beginning  lin*  21  kniffinOS 

Today  w*  are  exhibiting  *[  on*  of  th*  ]*  pr inary  features  of  our 
new  computer-aided  editing  system;  this  feature  has  been 
*[  designat]*ed  "the  substitution  dictionary. 

beginning  lin*  31  kniffinOS 

One  list  *[  compris]**s  *t  approximately]*  900  difficult  words 
that  frequently  appear  in  technical  annuals  while  the  second  list 
*C  compris]*es  *[  approximately]*  1800  suggested  substitutes  for 
th*  words  in  the  original  list. 

beginning  lin*  35  kniffinOS 

Each  substitute  was  selected  to  match  th*  shad*  of  meaning  of 
th*  difficult  word  that  it  might  replace,  and  additionally  each 
substitute  is  a  shorter,  more  faailiar,  and  aor*  frequently 
*[  utiliz] *ed  word. 

beginning  lin*  42  kniffinOS 

Th*  text  processor  is  than  *[  utiliz] *ed  to  eoapar*  each  word 
in  th*  text  with  the  list  of  difficult  words  in  th*  substitution 
dictionary. 

beginning  line  49  kniffinOS 

The  writer  must  then  determine  *[  which  ]*  word 
*(  modification] *s  can  be  aade  without  producing  an  alteration 
in  th*  meaning  of  th*  text. 

beginning  line  52  kniffin06 

A  readability  analysis  of  the  edited  text  can  then  be 
*(  accomplished]*  to  determine  if  th*  t*xtals  at  an  appropriate 
level  of  difficulty  for  th*  intended  audience. 

beginning  line  56  kniffln06 

*(  In  th*  near  future]*,  w*  hope  to  add  numerous  Innovations  to 
the  computer-aided  editing  system. 

beginning  line  59  kniffinOS 

*t  At  this  time,]*  we  believe  that  *(  desirable  benefits]*  will 
result  *(  by  means]*  of  taking  advantage  of  characteristics  that 
are  peculiar  to  certain  structures. 

beginning  lin*  63  knlffln06 

Other  benefits  could  *(  follow  after  ] *  we  *[  conduct  an  investigation] 
of  the  *(  manner  ]*  in  *(  which  ]*  writers  make  references  to 
other  parts  of  their  own  writing. 

beginning  line  66  kniffln06 

For  example,  w*  believe  that  th*  identification  of  passive  voice, 
anaphora,  and  inference  loading  may  be  *(  practicable]*. 

beginning  lin*  70  kniffin06 
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Furthermore,  w*  ara  planning  to  •(  laplaaant  ]*  tha  U. 
baginning  lina  71  kniffinOS 

Navy's  4000  word  controlled  vocabulary  and  to  *[  fabricate] *  our 
own  "Controllad  Logistics  Vocabulary. 

beginning  lina  72  kniffinOS 

*  Finally,  if  wa  *[  coupla  togatbar] •  tha  rasaarch  on  word  and 
phrasa  substitution,  parts  <*£  spaach  analysis,  and  syntax  rolas, 
w*  will  have  tha  *(  necesr ».y  requisite] *s  for 
*[  subsaquantl *  translation  from  English  to  foraign  languagas. 

Ella  kni£fin06:  number  of  lines  77  number  of  phrases  found  30 


PHRASE 


Table  of  Substitutions 
SUBSTITUTION 


accomplished:  use  "done*  for  "  accomplished" 
anticipate:  use  "expect"  for  "  anticipate" 

approximately:  use  "about,  nearly,  almost*  fot  *  approximately* 
at  this  time:  use  "now"  for  *  at  this  time" 
by  means:  use  "with,  by,  through"  for  "  by  means  of* 
compris:  use  "includes"  for  "  comprise* 

conduct  an  investigation:  use  "investigate"  for  "  conduct  an  investigation  of* 

coupla  together:  use  "couple"  for  "  coupla  together" 

designs t:  use  "appoint,  name"  for  "  daslgnata* 

desirable  benefits:  use  "benefits*  for  *  desirable  benefits" 

endeavor:  use  "try"  for  "  endeavor" 

fabricate:  us*  "hand  made,  manufactured,  fabricated*  for  "  man  made* 
fabricate:  use  "make,  build"  for  "  fabricate" 

facilitat:  us*  "ease,  simplify,  help.  Improve*  for  *  facilitate" 

follow  after:  use  "follow"  for  "  follow  after" 

implement:  us*  "execute,  fulfill,  achieve"  for  *  implement* 

in  the  near  future:  use  "soon"  for  "  in  the  near  future" 

manner :  use  "like,  as"  for  "  after  the  manner  of" 

manner:  use  "precisely,  etc."  for  "  in  a  precis*  manner" 

manner:  use  "similarly"  for  "  in  a  similar  manner" 

manner:  use  "way"  for  "  manner" 

modification:  use  "change"  for  "  modification" 

necessary  requisite:  us*  "requisite"  for  "  necessary  requisite* 

one  of  the:  use  "one,  a"  for  "  on*  of  the" 

practicable:  use  possible"  for  "  practicable” 

subsequent:  use  "later,  after"  for  "  subsequent  to" 

subsequent:  use  "next,  later,  further"  for  "  subsequent" 

utillz:  use  "use"  for  *  utilize" 

which:  us*  ""that"  when  clause  is  restrictive"  for  •  which" 
which:  use  "of  whic.n"  for  "  of  that" 
which:  us*  "when*  for  "  at  which  time" 


*  Not  all  the  revisions  will  be  appropriate  for  your  document. 

*  When  there  is  more  than  on*  suggestion  for  just  one  bracketed 
word,  you  will  have  to  choose  the  case  chat  fits  your  us*. 
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*  Capitalized  words  ar*  instructions,  not  suggestions. 

NOTE:  If  you  want  this  program  to  look  for  additional  phrasas 
or  to  stop  looking  for  soma,  for  instanc*  to  stop 
flagging  •impact,*  typ*  th*  command  dictadd. 

•••*••*•*•*«**•**••***«***  SPLIT  INFINITIVES  **************< 
For  file  kniffinOfi: 

No  split  infinitives  found 
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file  kniffin^6:  number  of  lines  79  number  of  phrases  found  0 


ORG  OUTPUT  FOR  kniffin06 


SAMPLE  6 

Because  our  endeavors  to  ameliorate  readability  and  text 
processing  are  familiar  at  numerous  echelons  of  th* 
military,  th*  requirement  for  an  alteration  in  our  standard 
demonstration  therefor*  became  obvious.  W*  anticipate  that 
subsequent  to  the  termination  oi  this  demonstration,  th* 
human  propensity  to  forget  all  th*  technicalities  will  take 
effect;  however,  by  retaining  th*  sample  transcriptions 
provided  to  you,  you  can  facilitate  your  memory. 

Today  we  are  exhibiting  on*  of  th*  primary  features  of  our 
new  computer-aided  editing  system;  this  feature  has  been 
designated  "the  substitution  dictionary.  Each  substitute 
was  selected  to  match  th*  shade  of  meaning  of  the  difficult 
word  that  it  might  replace,  and  additionally  each  substitute 
is  a  shorter,  more  familiar,  and  more  frequently  utilized 
word. 

Frequently  a  writer  ascertains  from  readability  analysis 
that  a  text  is  likely  to  be  too  difficult  for  th*  Intended 
audience.  A  readability  analysis  of  th*  edited  text  can 
then  be  accomplished  to  determine  if  the  text  is  at  an 
appropriate  level  of  difficulty  for  the  intended  audience. 

In  th*  near  future,  w*  hop*  to  add  numerous  innovations  to 
the  computer-aided  editing  system.  Finally,  if  w*  couple 
together  the  research  on  word  and  phrase  substitution,  parts 
of  speech  analysis,  and  syntax  roles,  w*  will  have  th* 
necessary  requisites  for  subsequent  translation  from  English 
to  foreign  languages. 
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BECAUSE  TOUR  TEXT  IS  SHORT  (<  2000  WORDS  fc  <  100  SENTENCES), 
THE  FOLLOWING  ANALYSIS  MAY  BE  MISLEADING. 

NOTE:  Your  document  is  being  compared  against  standards 
darivad  from  30  technical  memoranda,  classified  as  good 
by  managers  in  the  research  area  of  Bell  Laboratories. 


READABILITY 

The  Kincaid  readability  formula  predicts  that  your  text 
can  be  read  by  someone  with  16  or  more  years  of  schooling, 
which  is  rather  high  for  this  type  of  document.  Good  tech¬ 
nical  documents  average  close  to  13th  grade  level,  even 
though  the  audience  has  more  education  than  that* 

This  text  includes  many  long  words.  Consider  running 
the  syllable  counting  program,  svl.  to  look  at  the  words  in 
this  text  with  five  or  more  syllables.  To  do  this  type  the 
following  command  when  this  program  is  done. 

syl  -5  filename 

If  most  of  the  long  words  are  technical  terms  that  you  must 
use,  consider  providing  a  glossary  of  terms  to  make  this 
paper  easier  to  read.  If  the  words  aren't  technical  terms, 
use  shorter  words  wherever  you  can.  *In  changing  your  text, 
be  sure  not  to  use  several  different  words  for  the  same 
concept;  such  synonyms  are  frequently  confusing  to  the 
reader. 

VARIATION 

You  have  an  appropriate  distribution  of  sentence  types. 

SENTENCE  STRUCTURE 

Passives  and  Nominal izatlons 

You  have  appropriately  limited  your  use  of  passives  and 
nominalizations  (nouns  made  from  verbs,  e.g.  "description"). 

PROSE  OUTPUTS 

Options 

You  can  request  that  your  document  be  compared  against 
different  standards;  typing  -t  with  the  prose  command,  e.g., 

prose  -t  filename 

will  compare  your  text  against  training  documents. 

A  -s  option  will  provide  a  very  short  version  of  the 
prose  output. 
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proa*  -a  filename 

1 f  you  already  hav*  a  atyla  tabla  In  a  £11*,  you  can 
sav*  elm*  by  ualng  it  aa  th*  input  to  proa*  rath*r  than  th* 
textfil*.  To  do  ehla,  pr*c*d*  th*  style  table  filename  with 
a  -£,  e.g.. 


proa*  -£  styl*tabl*-f ilenam* 

All  th*  option*  can  b*  a*l*ct*d  at  th*  aaa*  tin*  and 
listed  in  any  order. 

proa*  -£  styl*table-f ilenam*  -a  -t 


Statistics 


Th*  tabl*  of  statistics  generated  by  th*  program  style 
can  be  found  in  your  file  styl.tmp.  If  you  want  to  loot  at 
it  type: 


cat  styl.tmp 

You  can  also  use  th*  match  program,  which  provides  a  better 
format,  type: 

match  styl.tmp 

If  you  ar*  not  interested  in  th*  £11*,  r*mov*  It  by  typing: 

rm  styl.tmp 

ORGANIZATION 

The  prose  program  cannot  check  th*  content  or 
organization  of  your  text.  On*  way  to  look  at  th*  overall 
structure  of  your  text  is  to  us*  grep  to  list  all  th* 
headings  th't  were  specified  for  th*  mm  formatter.  To  do 
this,  type: 


grep  '~\.H'  filename 

You  can  also  use  th*  organization  program,  org.  to  look 
at  th*  structure  of  your  text.  Org  will  format  your  paper 
with  all  th*  headings  and  paragraph  divisions  intact,  but 
will  only  print  the  first  and  last  sentence  of  *ach 
paragraph  in  your  text  so  you  can  check  your  flow  of  ideas. 

org  filename 
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Taxes  differ  in  th*  extant  to  which  they  refer  to 
concrete  objects  and  abstract  Ideas.  Concrete  objects, 
places,  or  things  can  be  seen,  heard,  felt,  smelled,  or 
tested.  Abstract  ideas,  on  the  other  hand,  cannot  be 
experienced  by  our  senses.  Proa  th*  results  of 
psychological  research,  w*  know  that  concrete  texts  are 
easier  to  read,  easier  to  use,  and  easier  to  reaeaber. 

In  file  akniffin06,a  3.7  percent  of  th*  words  are  abstract  words, 
which  is  a  high  score. 


Texts  with  more  than  about  2%  abstract  words  are 
abstract.  A  sample  of  Plato's  Symposium  has  4.41%  abstract 
words.  It  begins,  aFor  we  have  a  eustoa,  and  according  to 
our  custom  any  service  to  another  under  th*  idea  that  he 
will  be  improved..."  On  th*  other  hand,  a  text  with  no 
abstract  words  contains  this  passage:  aTh*  explosion  of  a 
gaseous  mixture  such  as  hydrogen  and  oxygen,...* 

One  way  to  improve  such  text  would  be  to  add  concrete 
examples  to  explain  th*  abstract  ideas. 

The  abstract  words  in  file  akniffin06a  are  stored  in  file 
"ab.kniff in06a.  Remove  it  if  you  wish. 

FILS  ab.kniff in06 

3  substitute 
2  technical 
2  future 
2  believe 
1  standard 
1  original 
1  objective 
1  necessary 
1  memory 
1  forget 
1  compare 
1  advantage 


Appendix  9 


Aug  24  13:04  1982  SHORT  PROSE  OUTPUTS  WITH  DIFFERENT  COMPARISONS  Pag*  1 


pros*  -t  -s  - f  sty.kniff in06 

BECAUSE  YOUR  TEXT  IS  SHORT  (<  2000  WORDS  «  <  100  SENTENCES) , 

THE  FOLLOWING  ANALYSIS  MAY  BE  MISLEADING. 

Compared  to  training  material. 

Reading  grade  level— 16.2:  Very  high,  Good  score  *  >7.8  -  12.4 
Variation— Too  many  compound  *  compound-complex  sentences  (27%). 
—Sentences  are  long— avg  length  ■  24.4  words 

—Good  length  *  15.0  to  20.2 
>>Short*n  sentences  by  dividing  into  simple  and  complex. 
Passives— 13.0%:  Good 

Nominalizations— 4.0%:  High,  Good  score  •  0%  -  3.4% 
pros*  -tm  -s  -f  sty.kniffin06 

BECAUSE  YOUR  TEXT  IS  SHORT  (<  2000  WORDS  6  <  100  SENTENCES), 

THE  FOLLOWING  ANALYSIS  MAY  BE  MISLEADING. 

Compared  to  technical  papers. 

Reading  grad*  level— 16.2:  High,  Good  score  •  >10.1  -  15.0 
Variation— Good  sentence  type  distribution. 

Passives— 13.0%:  Good 
Nominalizations— 4.0%:  Good 
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READABILITY  RESULTS 


Number  of  Sentences 
21 

Aver.  Number  of  Words 
per  Sentence 
22.19 


Number  of  Words 
466 


3  Number  of  Syllables 
864 

Avg.  Number  of  Syllables 
per  Word 
1.85 


GRADE  LEVEL 
14.9 


(Based  on  DOD  Readability  Standard) 


WORDS  NOT  ON  COMMON  WORD  LISTS 


WORD  FREQ 

alteration  2 
alterntive  1 
amalgamation  1 
ameliorate  1 
anaphora  1 
audience  2 
augment  1 
computer-aided  2 
desirable  1 
dictionary  1 
elementary  1 
example  1 
fabricate  1 
inference  1 
innovations  1 


WORD  FREQ 

non-technical  1 
ongoing  1 
practicable  1 
propensity  1 
readability  4 
requisites  1 
roles  1 
substitution  4 
syntax  1 
technicalities  1 
transcriptions  1 
translation  1 
vocabulary  1 
writer  2 
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Because  our  <endeavors><*TRIES/*>  to  [ameliorate]  [readability] 
and  text  processing  are  familiar  at  <numerousX*MANY/MOST*> 
<echelonsX*L£VELS/*>  of  military,  the  <requireraentX*NEED/*> 
for  an  [alteration]  in  our  standard  demonstration 
<thereforeX*SO/*>  became  obvious. <*031*>  Accordingly , X*SO/*> 
you  are  <observingX*SEEING/OBEYING*>  an  [amalgamation]  of  the 
products  of  our  .  [ongoing]  and  future  research  with  our 
<objectiveX*AlM/GOAL*>  being  to  <exhibitX*SHOW/*>  a 
<consolidatedX*UNITED/MADE  FIRM*>  demonstration  of  our  efforts 
at  producing  <benef icialX*HELPFUL/*> 

<modif icationsX*CHANGES/*>  in  both  text  and  text 
processing. <*037*X*  TOO  MANY  (07)  PREPOSITIONS  *>  We 
<anticipateX*EXPECT/*>  that  Subsequent  toX*APTER/LATER*>  the 
<termination  of X*ENDING/FINISHING*>  this  demonstration,  the 
human  [propensity]  to  forget  all  the  [technicalities]  will  take 
Affect; X*MAKE/BRING  ABOOT*>  however,  by 
<retainingX*KEEPlNG/*>  the  sample  [transcriptions] 
<provided><*GAVE/GIVEN/SUPPLIED*>  to  you,  you  can 
<facilitateX*EASE/HELP*>  your  memory.  Today  we  are 
<exhibitingX*SHOWING/*>  one  of  the  primary  features  of  our  new 
[computer-aided]  editing  system;  this  feature  has  been 
<designatedX*CERTAIN/CHOSEN*>  "the  [substitution] 

[dictionary."]  One  purpose  of  a  [substitution]  [dictionary]  is 
to  [augment]  [readability]  by  suggesting  [alternative] 
[elementary]  words  to  replace  the  difficult  [non-technical] 
words  in  a  text.<*024>  The  [dictionary] 
<incorporatesX*8LENDS/JOINS*>  two  word  lists.  One  list 
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<corapr isesX*FORMS/INCLUDES*>  approximately  X*ABOUT/*>  900 
difficult  words  that  frequently  <appearX*SEEM/*>  in  technical 
manuals  while  the  second  list  <corapr  isesX  *FORMS/ INCLUDES  *> 
<approxiraatelyX*A80UT/*>  1800  suggested  substitutes  for  the 
words  in  the  original  list.<*029*>  Each  substitute  was 
<selectedX*CERTAIN/*>  to  match  the  shade  of  meaning  of  the 
difficult  word  that  it  might  replace/  and  additionally  each 
substitute  is  a  shorter/  more  familiar,  and  more  frequently 
<utilizedX (USED/*>  word.<*032*>  Frequently  a  [writer] 
<ascertainsX*FINDS  OUT/LEARNS*>  from  [readability]  analysis 
that  a  text  is  likely  to  be  too  difficult  for  the  intended 
[audience.]  The  text  processor  is  then  <utilizedX*USED/*>  to 
compare  each  word  in  the  text  with  the  list  of  difficult  words 
in  the  [substitution]  [dictionary.  ]  <*023*X*  TOO  MANY  (05) 
PREPOSITIONS  *>  When  a  word  in  the  text  corresponds  to  a  word  in 
the  difficult  word  list,  the  text  processor  prints  out  the 
corresponding  substitute  words. <*024*>  The  [writer]  must  then 
<determineX*DECIDE/FIGURE*>  which  word 

Cmodif icationsX*CHANGES/*>  can  then  be  made<*  PASSIVE  VOICE  *> 
without  producing  an  [alteration]  in  the  meaning  of  the  text.  A 
[readability]  analysis  of  the  edited  text  can  then  be 
<accomplishedX*CARRIED  OUT/DID/DONE* >  to 
<determineX*DECIDE/FIGURE*>  if  the  text  is  at  an 
<appropr iateX*PROPER/RIGHT*>  level  of  difficulty  for  the 
intended  [audience.  ]  <*027*X*TOO  MANY  (05)  PREPOSITIONS  *>  In 
the  near  future,  we  hope  to  add  <nuraerousX*MANY/MOST*> 
(innovations]  to  the  [computer-aided]  editing  system. <*  TOO  MANY 
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(04)  PREPOSITIONS  *>  At  this  time,  we  believe  that  [desireable] 
<bene£ itsX*HELPS/IS  HELPED* >  will  result  by  means  of  taking 
advantage  of  characteristics  that  are  <peculiar  to><*RELATING/*> 
certain  structures. <*023*>  Other  <benef its><*HELPS/IS  HELPED* > 
could  follow  after  we  conduct  an  investigation  of  the  manner  in 
which  writers  make  references  to  other  parts  of  their  own 
writing. <*024*><*TOO  MANY  (05)  PREPOSITIONS  *>  For  [example,]  we 
believe  that  the  identification  of  passive  voice,  [anaphora,] 
and  (interference]  loading  may  be  [practicable.]  Futhermore,  we 
are  planning  to  <impleraentX*CARR¥  OUT/DO*>  the  U.S.  Navy's  4000 
word  controlled  [vocabulary]  and  to  [fabricate]  our  own 
"Controlled  Logistics  Vocabulary."  Finally,  if <*SUBORINATE 
CLAUSE  *>  we  couple  together  the  research  on  word  and  phase 
[substitution, ] <*  CLAUSE  TOO  LONG  *>  parts  of  speech  analysis, 
and  [syntax]  [roles,]  we  will  have  the  necessary  [requisites] 
for  <subsequent><*LATER/NEXT*>  [translation]  from  English  to 
foreign  languages. <*033*> 
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NAME  OF  SAMPLE  TEXT:  SAMPLE  6  17  SEP  82 


File  begins  with: 

Because  our  endeavors  to  ameliorate  readability  and  text 
processing  are  familiar  at  numerous  echelons  of  the  military,  the 


LONG  WORDS: 

endeavors 

ameliorate 

readability 

processing 

familiar 

numerous 

echelons 

military 

requirement 

alteration 

demonstration 

therefore 

obvious 

Accordingly 

observing 

amalgamation 

objective 

exhibit 

consolidated 

demonstration 

producing 

beneficial 

modifications 

processing 

anticipate 

subsequent 

termination 

demonstration 

propensity 

technicalities 

however 

retaining 

transcriptions 

provided 

facilitate 

memory 

exhibiting 

primary 

computer-aided 

producing  - ___ 

analysis 

— — *  alteration  . 

edited 

_ —— -  readability 

accomplished 

determine 

appropriate 

difficulty 

intended 

numerous 

innovations 

computer-aided 

editing 

desirable 

benefits 

advantage 

characteristics 

peculiar 

benefits 

investigation 

references 

example 

identification 

anaphora 

inference 

practicable 

Furthermore 

implement 

vocabulary 

fabricate 

Logistics 

Vocabulary 

Finally 

together 

substitution 

analysis 

necessary 

requisites 

subsequent 

translation 

languages 

SUMMARY  AND  CALCULATIONS:  SUMMARY  AND  CALCULATIONS: 


NUMBER  OF  SENTENCES-  21 
NUMBER  OF  WORDS-  463 
NUMBER  OF  SYLLABLES-  869 
AVERAGE  SENTENCE  LENGTH-  22.0 
AVG  SYLLABLES  PER  WORD-  1.88 
FL-KIN  GRADE  LEVEL  EQUIV-  >15 


NUMBER  OF  SENTENCES-  21 
NUMBER  OF  WORDS-  463 
NUMBER  OF  SYLLABLES-  869 
AVERAGE  SENTENCE  LENGTH-  22.0 
AVG  SYLLABLES  PER  WORD-  1.88 
FLESCH  INDEX-  25.7 
GRADE  LEVEL  EQUIV-  16.6 
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NAME  0?  SAMPLE  TEXT:  SAMPLE  6 


Because  our  endeavors  to  ameliorate  readability  and  text 

- endeavor  try,  attempt 

- ameliorate  improve,  better 

processing  are  familiar  at  numerous  echelons  of  the  military,  the 

- familiar  well  known 

- numerous  many,  some 

- echelon  level 

requirement  for  an  alteration  in  our  standard  demonstration  therefore 

- requirement  need 

- alteration  change 

- demonstration  show 

- therefore  so 

became  obvious.  Accordingly,  you  are  observing  an  amalgamation  of 

- obvious  plain,  clear 

••-SENTENCE  GREATER  THAN  20  WORDS.-** 

- Accordingly  therefore,  so,  then 

- observing  noting,  seeing 

—amalgamation  combination,  blend,  mixture 

the  products  of  our  ongoing  and  future  research  with  our  objective 

- ongoing  present 

- objective  aim,  goal 

being  to  exhibit  a  consolidated  demonstration  of  our  efforts  at  pro- 

- exhibit  show,  present 

- consolidate  unite,  combine,  join 

— -demonstration  show 

ducing  beneficial  modifications  in  both  text  and  text  processing.  We 

- producing  making 

- beneficial  helpful 

- modification  change 

••-SENTENCE  GREATER  THAN  20  WORDS.-** 

anticipate  that  subsequent  to  the  termination  of  this  demonstration, 

- anticipate  expect 

- subsequent  next,  later,  after 

- termination  end,  conclusion 

—demonstration  show 

the  human  propensity  to  forget  all  the  technicalities  will  take 

- propensity  tendency 

- technicalities  details 
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effect;  however,  by  retaining  the  sample  transcriptions  provided  to 
••-SENTENCE  GREATER  THAN  20  WORDS.-** 

- however  but ,  though 

- retaining  keeping,  holding 

—transcription  copy 
- provided  given 

you,  you  can  facilitate  your  memory. 

- facilitate  make  easy,  help 

Today  we  are  exhibiting  one  of  the  primary  features  of  our  new 

- exhibiting  showing,  presenting 

- primary  major,  first,  main,  basic 

computer-aided  editing  system;  this  feature  has  been  designated  "the 
- designate  name,  appoint,  choose,  pick,  select 

substitution  dictionary."  One  purpose  of  a  substitution  dictionary 

is  to  augment  readability  by  suggesting  alternative  elementary  words 
—augment  increase 

—alternative  choice,  choice  of,  option 
- elementary  basic,  simple 

to  replace  the  difficult  non-technical  words  in  a  text.  The  diction- 
- — difficult  hard 

••-SENTENCE  GREATER  THAN  20  WORDS.-** 

ary  incorporates  two  word  lists.  One  list  comprises  approximately 

- incorporate  combine,  include,  join 

— comprise  consist,  contain,  include,  make  up 
—approximately  about,  almost 

900  difficult  words  that  frequently  appear  in  technical  manuals  while 

- difficult  hard 

—frequently  often 

the  second  list  comprises  approximately  1800  suggested  substitutes 

- comprise  consist,  contain,  include,  make  up 

—approximately  about,  almost 

for  the  words  in  the  original  list.  Each  substitute  was  selected  to 

- original  first,  new 

** -SENTENCE  GREATER  THAN  20  WORDS.-** 

match  the  shade  of  meaning  of  the  difficult  word  that  it  might 
—difficult  hard 

replace,  and  additionally  each  substitute  is  a  shorter,  more 
—additionally  too,  also 

familiar,  and  more  frequently  utilized  word. 

— -familiar  well  known 

- frequently  often 

- utilize  use 

** -SENTENCE  GREATER  THAN  20  WORDS.-** 
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frequently  a  writer  ascertains  from  readability  analysis  that  a 
- Frequently  often 

— ascertain  find  out,  learn,  make  sure 

text  is  likely  to  be  too  difficult  for  the  intended  audience.  The 
—difficult  hard 

text  processor  is  then  utilized  to  compare  each  word  in  the  text  with 
- utilize  use 

the  list  of  difficult  words  in  the  substitution  dictionary.  When  a 
- difficult  hard 

•♦-SENTENCE  GREATER  THAN  20  WORDS.-** 

word  in  the  text  corresponds  to  a  word  in  the  difficult  word  list, 

- correspond  agree,  match 

- difficult  hard 

the  text  processor  prints  out  the  corresponding  substitute  words. 

- corresponding  agreeing,  matching 

** -SENTENCE  GREATER  THAN  20  WORDS.-** 

The  writer  must  then  determine  which  word  modifications  can  be  made 

- determine  decide,  find  out 

—modification  change 

without  producing  an  alteration  in  the  meaning  of  the  text.  A  read- 

- producing  making 

- alteration  change 

••-SENTENCE  GREATER  THAN  20  WORDS.-** 

ability  analysis  of  the  edited  text  can  then  be  accomplished  to 
- accomplished  expert,  done 

determine  if  the  text  is  at  an  appropriate  level  of  difficulty  for 
— -determine  decide,  find  out 

- appropriate  proper,  set  aside 

—difficult  hard 

the  intended  audience. 

** -SENTENCE  GREATER  THAN  20  WORDS.-** 

In  the  near  future,  we  hope  to  add  numerous  innovations  to  the 
—numerous  many,  some 
- innovation  change 

computer-aided  editing  system.  At  this  time,  we  believe  that  desir¬ 
able  benefits  will  result  by  means  of  taking  advantage  of  character- 
- — benefit  help 

istics  that  are  peculiar  to  certain  structures.  Other  benefits  could 
— -characteristic  feature,  quality,  trait 
—peculiar  odd,  strange,  special 
** -SENTENCE  GREATER  THAN  20  WORDS.-** 

—benefit  help 
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.follow  after  we  conduct  an  Investigation  of  the  manner  in  which 

writers  make  references  to  other  parts  of  their  own  writing.  For 
** -SENTENCE  GREATER  THAN  20  WORDS.-** 

example,  we  believe  that  the  identification  of  passive  voice, 

anaphora,  and  inference  loading  may  be  practicable.  Furthermore,  we 

- practicable  can  be  done,  possible 

- Furthermore  also,  too,  besides 

are  planning  to  implement  the  U.S.  Navy's  4000  word  controlled  vocab- 
- implement  follow,  effect,  tool 

ulary  and  to  fabricate  our  own  "Controlled  Logistics  Vocabulary." 

- fabricate  build,  make 

Finally,  if  we  couple  together  the  research  on  word  and  phrase 

substitution,  parts  of  speech  analysis,  and  syntax  roles,  we  will 

have  the  necessary  requisites  for  subsequent  translation  from  English 
—necessary  needed 
— -requisite  needed 
- subsequent  next,  later,  after 

to  foreign  languages. 

""-SENTENCE  GREATER  THAN  20  WORDS.-** 
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NAME  Of  SAMPLE  TEXT:  SAMPLE  6 


NEG/NOM/ABSTRACT  WORD  CHECK 

Because  our  endeavors  Co  ameliorate  readability  and  CexC  processing  are  familiar 

at  numerous  echelons  of  Che  military  che  requirement  for  an  alteration  in 

'NOM  'NOM 

our  standard  demonstration  therefore  became  obvious  Accordingly  you  are  observing 
'NOM 

an  amalgamation  of  the  products  of  our  ongoing  and  future  research  with  our 
'  NOM 

objective  being  to  exhibit  a  consolidated  demonstration  of  our  efforts  at 

'NOM  'ABS 

producing  beneficial  modifications  in  both  text  and  text  processing  We  anticipate 

'  NOM 

that  subsequent  to  the  termination  of  this  demonstration  che  human  propensity 

' NOM  ' NOM 

to  forget  all  che  technicalities  will  take  effect  however  by  retaining  che 

sample  transcriptions  provided  to  you  you  can  facilitate  your  memory  Today 
'  NOM 

we  are  exhibiting  one  of  che  primary  features  of  our  new  computer-*aided  editing 

system  this  feature  has  been  designated  the  substitution  dictionary  One  purpose 

'NOM 

of  a  substitution  dictionary  is  to  augment  readability  by  suggesting  alternative 
'NOM 

elementary  words  to  replace  the  difficult  non-technical  words  in  a  text  The 

dictionary  incorporates  two  word  lists  One  list  comprises  approximately  900 

difficult  words  that  frequently  appear  in  technical  manuals  while  the  second 

list  comprises  approximately  1800  suggested  substitutes  for  the  words  in 

'ABS 

the  original  list  Each  substitute  was  selected  to  match  che  shade  of  meaning 

'ABS 

of  che  difficult  word  chat  it  might  replace  and  additionally  each  substitute 

'ABS 

is  a  shorter  more  familiar  and  more  frequently  utilized  word  Frequently  a 

writer  ascertains  from  readability  analysis  that  a  text  is  likely  Co  be  too 

difficult  for  che  intended  audience  The  text  processor  is  then  utilized  to 

compare  each  word  in  the  text  with  the  list  of  difficult  words  in  che  substitution 

'NOM 

dictionary  When  a  word  in  the  text  corresponds  to  a  word  in  the  difficult 

word  list  che  text  processor  prints  out  che  corresponding  substitute  words 

'ABS 
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The  writer  must  then  determine  which  word  modifications  can  be  made  without 

'  NOM 

producing  an  alteration  in  the  aaaning  of  the  text  A  readability  analyaia 
'NOM 

of  the  edited  text  can  then  be  accomplished  to  determine  if  the  text  is  at 

an  appropriate  level  of  difficulty  for  the  intended  audience  In  the  near 

future  we  hope  to  add  numerous  innovations  to  the  computer-aided  editing 

'NOM 

system  At  this  time  we  believe  that  desirable  benefits  will  result  by  means 

of  talcing  advantage  of  characteristics  that  are  peculiar  to  certain  structures 
'ABS 

Other  benefits  could  follow  after  we  conduct  an  investigation  of  the  manner 

'NOM' ABS 

in  which  writers  make  references  to  other  parts  of  their  own  writing  For 

'NOM 

example  we  believe  chat  the  identification  of  passive  voice  anaphora  and 

'NOM 

inference  loading  may  be  practicable  Furthermore  we  are  planning  to  implement 
'NOM 

the  U.S  Navy's  4000  word  controlled  vocabulary  and  to  fabricate  our  own  Controlled 

Logistics  Vocabulary  Finally  if  we  couple  together  the  research  on  word  and 

phrase  substitution  parts  of  speech  analysis  and  syntax  roles  we  will  have 
'NOM 

che  necessary  requisites  for  subsequent  translation  from  English  to  foreign 

'NOM 

languages 
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'SOFTWARE  DOCUMENTAT 


MAY  10,  1984 


0  N  ' 


Martin  C.  Olson 

APPLIED  TECHM0L06Y  CORPORATION 


HIERARCHY  CHART 


"BUBBLE-CHARTING 


INPUT  -  PROCESS  -  OUTPUT  (IPO)  CHART 


IKPOT 


PROCESS 


OUTPUT 


SOFTWARE  DOCUMENTATION  PROCESS 
"SIMPLIFIED* 


BASIC  SEQUENCES  OF  STRUCTURED  PROGRAMMING 


. 


STRUCTURED  PROGRAM  CODE 


0900 

INPUT  "HOW 

MANY  RECOROS  TO 

WRITE"*  JX 

1000 

OPEN  “0BB2 « 

“  FOR  OUTPUT  AS 

FILE  •2Xr  ORGAN  I  CAT 

1003 

FOR  KX  *  IX 

TO  JX 

1010 

FOR  IX  * 

OX  TO  7X 

1020 

INPUT 

"NAME  OF  BOOK"* 

BOOK. NAME* 

1030 

INPUT 

"RETRIEVAL  NUMBER"*  RET.NUMX 

ioao 

INPUT 

"SUBJECT  AREA"* 

SUB  J* 

1030 

MOVE  TO  »2X  >  FILL*  = 

IX  *  sax.  BOOK. NAME* 

1060 

NEXT  IX 

1070 

PUT  »2X 

1000 

NEXT  KX 

1090 

CLOSE  «2 

.  RET.NUMX,  SUB  J* 


P-6 


iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiHiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiilliniiii 


Illlllllllll 


STRUCTURED  PROGRAM  CODE  WITH  ANNOTATED  COMMENTS 


LCR 
ABT  : 

ab2: 


•TITLE  MYROUTINE 

•  ENTRY  START , M®  <  > 

RO 

subl3  #10,<I(ap)r2 

BRB  CONT 


BEGINNING  OE  ROUTINE 
CLEAR  REGISTER 
SUBRTACT  10 

BRANCH  TO  ANOTHFR  ROUTINE 


0 

0 

0 


MOVAL  STdJ.RO 

MOVZWL  (rO).rI 

MO  VL  <I(rO),RO 


GET  ADDRESS  OF  STRING 
DESCRIPTOR 

GET  LENGTH  OF  STRING 
GET  ADDRESS  OF  STRING 


0 

0 

0 

MO VL  #*A/ABCD/,R0 


compw  #*a/xy/,rO 


•ouad  ®aX123R/678X 

MO VL  #cA/AB/,RO 


;  MOVE  CHARACTERS  a,b,c,d 
;  INTO  RO  RIGHT  JUSTIFIED  WITH 
}  'a'  IN  LOW-ORDER  BYTE  AND  *D* 

S  IN  HIGH  ORDER  BYTE 
;  COMPARES  X  AND  Y  AS  ASCII 
;  CHARACTERS  WITH  CONTENTS  OF 
;  LOW  ORDER  2  BYTES  OF  RO 
;  GENERATE  R  BYTES  OF  ASCII  DATA 
;  MOVE  ASCII  CHARACTERS  AB  INTO 

;  rOj  'a*  in  low-order  bytej  *b* 
}  IN  NEXT;  AND  ZERO  THE  2  HIGH- 
;  ORDER  BYTES 


» 


» 


iiiiHiaiiiiiiiiiiiiiiHiiHiMiiiHiiiHiiiiiiMiiiiimiiiiiMiiiiiiiiiimiiiiiiimiiiitHiiniiiiiiiiiiNiNiiiiiniiiiiiiimfiiii£iniiiiiin 


» 


IT  SHOULD  BE  HARD  TO  UNDERSTAND  !!! 


«$(!'$  «»»tm 


■iiiiii^iiiiiiiiimiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiimiiiiiiiiiiitiiiiitimiiiiiiitiiimiiiiiiiiiiiiiiiiiiiiiiniiimimi 


REAL 

PROGRAMM 

ERS 

DON 

'  T 

WRITE  SPECS  . 

USERS 

SHOULD 

CONS 

I  DER 

THEMSELVES  LUCKY 

TO  GET 

ANY 

PROGR 

AMS  AT  ALL 

• 

.  .  AND  L 

IKE 

WHAT 

THEY  GET  MI 
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RAYTHEON 


RAYTHEON  COMPANY 
BEDFORD  LABORATORIES 
CONFIGURATION  MANAGEMENT 

OF 

COMPUTERIZED  DESIGN  DATA 


26th  ANNUAL  ADPA  TDD 
SAN  ANTONIO,  TEXAS 
81 1  MAY,  1984 


PRESENTED  BY: 

K.E.  FOSTER 
RAYTHEON  COMPANY 
MISSILE  SYSTEMS  DIVISION 


CONFIGURATION  MANAGEMENT 
CHALLENGES 


RAYTHEON 


•  DESIGN  AND  IMPLEMENT  AN  EFFECTIVE  CM  CONTROL  SYSTEM  IN  AN 
R&D  ENVIRONMENT  TO: 

•  CAPTURE  ENGINEERING  AUTOMATED  DESIGN  DATA 

•  USING  COMPUTERVISION  (C/V) 

•  CONTROL  THE  DESIGN  DATA  BASE 

•  IN  A  MULTI-PROGRAM  ENVIRONMENT 

•  UPDATE  THE  AUTHORIZED  DESIGN  IN  THE  DATA  BASE 

•  BUILD  HISTORICAL  RECORDS  OF  DESIGN  REVISIONS 

•  SECURE  THE  FILES  IN  A  CM  CONTROLLED  FACILITY 

•  CONTROL  ACCESS  TO  APPROVED  DESIGN  DATA 

•  PROVIDE  BACKUP  RECOVERY 


•  DESIGN  AND  IMPLEMENT  AN  EFFECTIVE  CM  CONTROL  SYSTEM  IN  AN 
R&D  ENVIRONMENT  TO: 

•  LET  ENGINEERING  DESIGN  EFFORTS  CONTINUE  WITHOUT  CM 
CONTROLS 

•  REDUCE  COSTS  OF  DRAWING  GENERATION/MAINTENANCE 

•  PROVIDE  INTERACTIVE  OUTPUT  TO  SUPPORT  SYSTEMS  INTERFACE 
(NETWORKING) 

•  DEVELOP  ALTERNATIVES  FOR  DELIVERABLE  DATA 


THE  RESPONSE 


•  CONFIGURATION  CONTROL  IS  ESTABLISHED  PRIOR  TO 
DOCUMENTATION  RELEASE/APPROVAL  CYCLES 

•  CM  IS  ON  SITE  IN  COMPUTER  CENTER 

•  DIRECT  INTERFACE  WITH  DESIGN  ACTIONS  —  SECURE 
DESIGN  OATA 

•  APPROVES  AUTHORIZED  CONFIGURATIONS  -PRIOR  TO 
UPDATE  CYCLES 

•  BUILDS  HISTORICAL  FILE  -  RELEASES/CHANGES 

•  ONSITE  LIBRARY  -  UNDER  CM  CONTROL 

•  CONTROL  BACKUP  (RECOVERY)  SYSTEM 

•  PASSWORD  CONTROL  -  AUTHORIZED  ACCESS  ONLY 

•  DESIGN  EFFORTS  CONTINUE  -  CM  HAS  AUTHORIZED 
CONFIGURATION 

•  CREATE  “PAPER”  DRAWINGS  —  MYLAR  ONLY  WHEN  REQUIRED 

•  C/V  DESIGNS  UPDATED  ON  CIV 

•  CREATE  “BRIDGE”  DATA  OUTPUT  -  FEED  ADMINISTRATIVE 
SYSTEMS 

•  CIV  OUTPUT  TAPE  COPY  -  COM  —  MICROFORM  +  PAPER 
DRAWINGS 

•  NETWORK  TIES  RAYTHEON  MANUFACTURING  FACILITIES 
TOGETHER 


COMPUTERVISION  SYSTEM 
PROFILE 

BEDFORD  LABORATORIES 


CURRENT  C/V  NETWORK 


•  BEDFORD  —  MULTIPLE  WORK  STATION  ENVIRONMENT 

•  NEW  DESIGNS  USE  C/V 

•  ALL  DATA  AVAILABLE  TO  ALL  WORK  STATIONS 

•  RELEASE  AND  USE  OF  DATA  IS  VIA  ELECTROSTATIC  PLOTTER  TO 
MAKE  DRAWINGS 

•  CENTRALIZED  FILES  SIMPLIFY  CM  - 

SINGLE  DATA  BASE  TO  CONTROL 
ON  “HOST”  COMPUTER 

•  MANUFACTURING  HAS  ACCESS  TO  ALL  DESIGN  INFORMATION 

•  RELEASE  TO  MANUFACTURING  CAN  BE  MADE  IN  BEST  FORM 

•  DATABASE 

•  MAGNETIC  TAPE 

•  COM 

•  HARDCOPY 

•  COMBINATION  OF  ABOVE 


PLANNING  CONSIDERATIONS 


•  UNDERSTANDING  THE  COMPUTERVISION  SYSTEM 

•  DEFINED  THE  CM  ROLE 

•  ESTABLISHED  A  WORKING  MODEL  (FLOW  AND  PROSE) 

•  TIMING  FACTORS  -  WHERE  IS  CM  INSERTED?  RESPONSE 
TIME  REQUIREMENTS  DEFINED 

•  DEVELOPMENT  OF  CM  TRAINING  PROGRAM 

•  CLASSROOM  TRAINING 

•  HANDS  ON  THE  SYSTEM 

•  DATA  BASE  PROTECTION  AND  STORAGE  CONCEPTS 

•  ASSIGN  CM  PERSONNEL  TO  C/V  FACILITY 

•  ONE  FULL  TIME  INDIVIDUAL  PLUS  BACKUP 

•  CREATE  A  SECURED  LIBRARY  FACILITY 

•  ON  SITE  —  LOCKED-FILES  —  RESTRICTED  ACCESS 

•  CM  HAS  DEDICATED  DISK  DRIVE 

•  PLUS  CM  CONTROLLED  DISK  PACKS 

•  ALL  CM  DATA  RESIDES  ON  HOST  COMPUTER 

•  IS  CENTRAL  CONTROL  POINT  FOR  ALL  WORK  STATIONS 

•  PROVISIONS  FOR  BACKUP  RECOVERY  SYSTEM 

•  TAPE  COPIES  STORED  OFFSITE  -  UNDER  CM  CONTROL 


q-4 


MANAGING  IMPLEMENTATION 


•  BUILD  A  CM  DATA  BASE  SYSTEM 

•  CREATED  FROM  DRAFTING  DATA  BASE 

•  AFTER  ENGINEERING  SIGNS  ELECTROSTATIC  PRINTER 
PREPARED  (PAPER)  DRAWINGS 

•  DRAFTING  FILE  ACCESSED  BY  CM  THRU  HOST  COMPUTER 

•  REFORMATTED  FOR  CM  RETRIEVAL  REQUIREMENTS 

•  PASSWORD  PROTECTED 

•  CM  APPLIES  SECURITY  PASSWORD 

•  CONTAINS  NEW  RELEASES  AND  UPDATE  DESIGN  DATA 

•  UNDER  CM  CONTROL  PRIOR  TO  CCB  APPROVALS 

•  NON-APPROVAL  BY  CCB  REQUIRES: 

•  CM  TO  PASS  SECURED  DATA  BACK  TO  DRAFTING  DATA  BASE 

•  DRAFTING  FILE  IS  RE  CREATED  FROM  THE  CM  DATA 
BASE  SINCE: 

•  CM  CONTROLS  THE  AUTHORIZED  CONFIGURATION 
SUBMITTED  TO  CCB 

•  OBTAIN  CCB  APPROVALS 

•  SIGNATURES  ON  ENGINEERING  RELEASE/CHANGE  ORDERS 

•  MICROFILM  PAPER  "MASTERS"  AND  RELEASE/CHANGE 
DOCUMENTATION 

•  CREATE  CM  BACKUP  FILES 

•  PERFORM  DATA  BASE  AUDITS 

•  HARD  COPY  vs  CM  DATA  BASE  RECORDS 


CONFIGURATION  MANAGEMENT 
OF 

COMPUTER  AUTOMATED  DESIGN 


DATA  BASE  STRUCTURE 
1.  DRAFTING  RECORD 


DEPT  NO.  REO  NO. 

PROJ CODE 

DOC  NO. 

SHEET  NO.  REV  | 

• 

ONE  SHEET  DRAWING 

7187 

XXXX 

SPSK  CAN 

7B7XXX 

R(X) 

• 

MULTI  SHEET  DRAWING 

7187 

XXXX 

SPSX  RAL 

797XXX 

SHX 

R(X) 

• 

PL’* 

7187 

XXXX 

SPSK  CAN 

PL787XXX 

R(X) ! 

• 

PL's  MULTI  SHEET 

7187 

XXXX 

SPSK  CAN 

PL787XXX 

SHX 

R(X) 

2.  CONFIGURATION  MANAGEMENT  RECORD 


PROJ  CODE 

DOC  NO. 

SHEET  NO. 

REV 

PASSWORD 

•  SPSK  CAN 

797XXX 

SHX 

R(X) 

XXXXXX 

Q-6 


ENGINEERING 

IORAFTING  I 
DESIGN  I 
ACTIONS  I 


CONFIGURATION  MANAGEMENT 
OF 

COMPUTER  AIDED  DESIGN 


DESIGN  RELEASE 


PREPARE 

ORAFTINQ 

FORMAT 


DATA  BASE  DISSEMINATION 


PRESENTED  TO  AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 
TECHNICAL  DOCUMENTATION  DIVISION  ANNUAL  MEETING 
SAN  ANTONIO,  TEXAS 
10  MAY  1984 

EARNEST  W.  DEADWYLER 


The  professional  community  represented  here  is  well  aware  of 
the  pr o I i ferat i on  of  data  bases  and  the  means  to  access  them 
which  have  been  developed  in  recent  years,  as  indicated  by 
previous  presentations  and  working  sessions.  This 
proliferation  has  led  to  increasing  interest  in  both  the 
Government  and  defense  industry  in  methods  for  improving 
access  to  the  data  bases  and  dissemination  of  information 
regarding  the  contents,  as  well  as  dissemination  of  the 
contents  themselves. 

The  purpose  of  my  presentation  is  to  acquaint  you  with 
several  activities  which  have  taken  place  recently  in  the 
Government/ i ndustry  defense  community  related  to  a  part  of 
this  area  of  interest.  One  result  of  this  activity  has  been 
a  suggestion  that  a  separate  section  be  formed  within  the 
Technical  Documentation  Division  to  focus  on  the  general 
subject  of  data  base  dissemination.  At  this  point  our  focus 
is  limited  but  we  hope  in  the  future  to  broaden  the  scope  to 
provide  a  ri^-ans  of  linking  the  common  interest  in  data  base 
dissemination  among  all  the  sections. 

A  good  starting  point  for  looking  at  data  base  dissemination 
is  the  technical  information  centers  or  technical  libraries 
of  defense  organizations  or  defense  contractors.  Typically, 
as  shown  on  this  chart,  these  activities  interface  with 
several  different  types  of  external  data  base. 

The  commercial  data  bases  (DIALOG,  ORBIT,  AND  BRS 
( B i b li ograph i c  Retrieval  Service))  shown  in  the  lower  left 
box  provide  access  to  several  hundred  technical  journal  and 
periodical  bibliographic  data  bases,  including  many  foreign 
publications.  Technical  librarians  are  able  to  conduct  on 
line  searches  of  these  data  bases  and  obtain  printouts  of 
search  results  in  varying  degrees  of  detail.  Documents  may 
be  ordered  online  for  expedited  delivery  by  mail,  or  they  may 
be  obtained  from  the  local  1 ibrary. 


The  Defense  Marketing  Service  provides  a  computer  searchable 
data  base  conta i n i ng  information  which  has  for  many  years 
been  provided  in  hard  copy  form  to  subscribers.  It  also 
includes  additional  defense  related  documents,  such  as  the 
text  of  defense  official's  presentations  to  Congress  and 
defense  budget  information  when  released  to  the  public. 
Contract  and  market  intelligence  information  can  be 
researched  and  results  compiled  quickly  using  online  searches 
to  avoid  time  consuming  manual  searches  through  many  volumes 
of  hard  copy. 

The  On  1  ine  Computer  Library  Center  maintains  an  extensive 
data  base  of  catalog  information  for  newly  published  books 
and  books  held  by  libraries  throughout  the  country.  It 
provides  ass i stance  to  subscribers  in  preparing  library  card 
catalogs  and  in  locating  and  obtaining  books  and  periodicals 
via  interlibrary  loans. 

Most  of  you  are  familiar  with  the  Defense  Technical 
Information  Center,  or  DT1C,  which  is  the  Defense 
Department's  repository  for  a  wide  range  of  technical  reports 
and  defense  research  and  development  planning  data.  The 
contents  include  the  R&D  program  planning  data  base,  which  is 
currently  in  a  holding  state  since  input  was  cutoff  by  DoD 
directive  in  June  1982.  I  will  have  more  to  say  about  this 
later.  The  data  bases  also  include  the  research  and 
technology  work  unit  information  system  (WU1S)  with  data 
concerning  work  in  progress,  the  technical  reports  data  base 
with  reports  of  work  completed,  and  an  independent  research 
arid  development  data  base.  The  latter  is  available  only  to 
government  agencies. 

There  are  currently  719  subscribers  to  the  Defense  RDT&E 
Online  System,  or  DROLS,  about  360  of  whom  are  contractors. 
Most  of  the  users  access  the  OTIC  data  bases  via  a  dialup 
terminal  .  These  users  are  able  to  conduct  on  1  ine  searches 
and  display  or  printout  unclassified  data  from  searches  and 
to  order  documents  on  line.  This  expedites  identifying  and 
obtaining  needed  documents  to  support  ongoing  research  and 
development  programs  and  program  planning.  103  users  (92 
Government  and  11  contractors)  have  the  capability  for  online 
access  and  display  of  classified  information  in  the  data 
bases  via  a  terminal  equipped  with  a  cr yptograph i c  interface. 
This  further  expedites  obtaining  data  through  the  ability  to 
obtain  c  lassified  data  at  the  tine  of  the  search,  rather  than 
having  to  wait  until  the  classified  search  results  are 
received  by  mail.  Unfortunate  1 y ,  the  procedures  for  obtaining 
classified  terminal  access  are  somewhat  cumbersome  and  time 
consuming  and  on  I y  a  1  imited  number  of  contrac:ors  have 
succeeded  in  acqu i r i ng  the  capability. 


In  addition  to  DT1C,  defense  R&D  technical  and  planning 
information  is  made  available  to  the  defense  community 
through  tri -service  industry  information  centers  in 
Washington,  Dayton,  and  Los  Angeles.  The  dedicated  staff  in 
these  agencies  works  hard  and  does  an  outstanding  job  with 
the  resources  available  to  meet  the  information  needs  of 
defense  industry;  however,  policies  and  procedures  imposed  by 
the  Department  of  Defense  frequently  make  it  very  difficult 
for  contractors  to  obtain  needed  information. 

The  need  to  improve  the  defense  technical  information  program 
was  recognized  over  three  years  ago.  On  17  and  18  March  1981 
Dr.  George  Gamota,  then  the  Director  of  the  Research  and 
Technical  Information  in  the  Office  of  the  Deputy 
Under  secretary  of  Defense  Research  and  Engineering  (Research 
and  Advanced  Technology)  sponsored  a  conference  for  research 
and  development  managers  to  discuss  ways  for  improvement. 
This  conference  brought  together  a  large  cross  section  of 
government  and  industry  research  and  development  managers. 
The  issues  addressed  included:  technical  information  program 
management ,  technical  document  production  and  access, 
computerized  information  systems  and  data  bases,  and 
information  transfer  services  and  applications. 

The  major  recommendations  developed  during  this  conference 
are  summarized  at  the  bottom  of  this  vugraph.  The  first 
r ecommendat i on  shown  has  been  implemented  and  Dr.  Leo  Young, 
current  Director  of  Research  and  Laboratory  Management  in 
dUSDRE ,  serves  as  the  DoD  focal  point  for  technical 
information.  Dr.  Young  has  also  implemented  the  second 
recommendation  with  the  formation  of  an  Information  for 
Industry  Committee  having  representatives  from  OSD  and  the 
three  services.  He  has  recently  indicated  that  a 
representative  of  OTIC  will  be  added  to  the  committee. 

As  far  as  is  known,  action  has  been  started  but  not  completed 
on  the  remaining  three  recommendations.  DTIC  has  reportedly 
compiled  a  data  base  with  information  on  over  400  defense 
related  data  bases,  but  this  data  base  has  been  given  only 
limited  distribution  and  is  not  available  to  contractors. 
Both  Government  and  contractor  users  report  continuing 
difficulty  with  obtaining  access  to  some  military 
publications,  such  as  specifications  and  standards,  technical 
orders,  and  technical  and  field  manuals.  A  military 
publications  user  group  has  been  formed  to  identify  problems 
and  seek  help  in  this  area. 

Comments  of  the  participants  in  the  working  session  on 
information  systems  and  data  bases  at  this  conference  are 
summarized  on  the  next  vugraph. 
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As  is  the  case  with  any  data  base  accessible  to  a  wide 
variety  of  users  it  was  considered  essential  that  the 
information  systems  be  user  oriented  and  that  users  be  able 
to  have  personal  contact  with  the  person  having  the  data  or 
entering  it  into  the  data  base  so  as  to  resolve  questions.  It 
was  also  emphasized  that  the  person  responsible  for  providing 
the  data  must  be  responsible  for  the  quality,  quantity,  and 
timeliness  of  the  data. 

The  necessity  for  multiple  levels  of  data  bases  and 
accessibility  was  noted,  with  each  dependent  upon  the 
composition  and  utilization  of  the  data  base.  It  was  also 
pointed  out  that  there  is  a  distinction  between  hard  fact 
data  and  planning  data.  The  Information  Analysis  Centers 
were  noted  as  having  a  unique  capability  to  interpret  hard 
data  and  go  beyond  the  basic  task  of  providing  factual  data 
or  identification  of  references  containing  data. 
Participants  in  this  conference  were  also  of  the  opinion  that 
the  technical  problems  associated  with  internetting  data 
bases  would  be  difficult  and  costly  to  resolve  and  that  for 
the  next  several  years  interface  with  the  data  bases  by  human 
operators  would  be  required. 

Almost  two  years  after  the  DoD  technical  information 
conference  for  R8.D  managers,  on  7  and  8  December  1982, 
another  conference  was  sponsored  by  OSD  to  assess  defense 
industry's  requirements  for  DoD  technical  and  planning 
information.  This  conference  included  working  sessions  on 
three  topics:  industry  perception  of  current  and  future 

scientific  and  technical  information  programs ,  technical 
information  and  planning  requirements  of  industry,  and 
improving  the  DoD/ industry  information  exchange  process. 

In  the  working  session  on  technical  information  and  planning 
requirements  for  industry  it  was  noted  that  contractors  were 
finding  increasing  difficulty  in  obtaining  defense 
requirements  and  planning  data  and  technical  information. 
The  difficulties  being  encountered  seemed  to  be  at 
variance  with  the  perceived  need  to  improve  the  acquisition 
process  expressed  in  the  Carlucci  initiatives  of  April  1981 
and  statements  regarding  the  Independent  Research  and 
Development  program  made  by  Dr.  Delauer  in  Congressional 
testimony  in  April  1982.  Guidance  from  OSD  regarding  the 
dissemination  of  information  and  data  to  industry  mentioned 
the  importance  of  seeking  ways  to  save  money,  maintaining  an 
ethical  distance  between  DoD  and  industry  without  becoming 
adversarial,  technical  collaboration  with  industry,  and 
creation  of  an  environment  which  encouraged  industry  to 
develop  innovative  concepts  complementing  and  broadening  the 
spectrum  of  concepts  developed  internally  within  DoD. 
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In  the  preceding  comments  1  have  tried  to  acquaint  you  with 
actions  taken  over  the  past  several  years  in  a  very  narrow 
area  of  data  base  dissemination.  The  number  and  extent  of 
data  bases  is  continual ly  increasing  in  all  segments  of 
industry  as  we  enter  the  age  of  the  "information  society". 
This  provides  major  challenges  to  maintain  familiarity  with 
the  wide  variety  of  highly  specialized  data  bases  and 
continuing  improvements  in  the  software  and  hardware  tools 
ava i lable  to  disseminate  them.  There  are  many  exciting 
developments  on  the  horizon  -  and  some  even  closer  -  which 
promise  significant  increases  in  our  capabilities  to  interact 
with  data  bases  and  extract  information  from  them. 

In  the  defense  area  one  of  the  most  interesting  developments 
is  a  gateway  system  along  the  lines  of  a  technical 
information  system  developed  by  Lawrence  Livermore 
Laborator i es  which  has  the  potential  to  revolutionize  the 
dissemination  of  data  base  information.  This  system  will 
provide  the  capability  to  link  people,  information  centers, 
and  computers  and  provide  a  very  simple  and  user  friendly 
interface  to  a  wide  variety  of  data  bases. 

The  system  would  have  the  capability  to  function  as  an 
electronic  switch,  protocol  translator,  super i nte 1 1 i gent 
terminal,  communications  interface,  and  transaction 
controller.  This  would  streamline,  speed  up,  and  modernize 
the  search  process  by  providing  a  fast  smart  robot  to  do  the 
drudge  work  of  data  access.  The  system  would  enable  the 
researcher  to  connect  to  a  variety  of  data  bases,  search  for 
and  locate  data,  and  obtain  a  single  printout  with  an 
appropr i ate  1 y  formatted  final  report  containing  the  search 
r esu Its. 

Considering  the  present  scope  of  activity  and  the  potential 
of  new  developments  such  as  this  we  believe  that  the 
formation  of  a  new  section  in  the  Technical  Documentation 
Division  is  appropriate  and  timely.  However;  even  with  the 
formation  of  a  new  section  we  realize  that  it  will  be 
difficult  to  cover  the  data  base  dissemination  field 
adequately.  Our  proposed  approach  is  to  begin  in  a  limited 
area  with  which  we  are  somewhat  familiar  and  where  there  are 
already  known  challenges,  then  to  expand  activity  as 
part i c i pat i on  and  interest  increases.  We  will  try  to  keep 
our  focus  within  manageable  limits  and  to  be  successful  in 
those  things  we  do  tackle  so  we  can  build  on  success.  The 
primary  focus  will  be  on  ways  to  improve  defense  productivity 
through  better  dissemination  and  utilization  of  data  base 


The  areas  which  have  been  identified  for  future  action 
i nc 1 ude : 

Working  with  the  DROLS  User  Council  and  DoD  Information  for 
Industry  Committee  to  seek  continued  improvement  in  the 
system. 

Seeking  improvements  in  the  procedures  for  qualified 
contractors  to  obtain  sponsorship  and  validations  required 
for  a  classified  terminal  interface  with  the  DTIC  data  bases. 

Seeking  improvement  in  the  accessibility  and  availability  of 
military  publications  for  all  users. 

Pushing  for  an  improvement  in  the  quality  and  timeliness  of 
the  research  and  development  planning  data  base  and  access  to 
it  by  OTIC  users. 

Working  with  other  sections  of  the  division  to  identify  and 
categorize  the  wide  variety  of  data  bases  in  use  and  ways  to 
improve  dissemination  and  linkage  among  them. 


A  key  focus  of  all  these  efforts  will  be  to  simplify  ways  in 
which  computer  resources  and  data  are  utilized. 


POD  TECHNICAL  INFORMATION  CONFERENCE  FOR  R&P  MANAGERS 

16-17  MARCH  1981 


•  OBJECTIVE: 

BRING  TOGETHER  A  LARGE  CROSS  SECTION  OF  OOD  INHOUSE  AND 
CONTRACTOR  SCIENTISTS,  ENGINEERS,  AND  TECHNICAL  MANAGERS 
TO  ASSIST  IN  PLANNING  THE  DEFENSE  SCIENTIFIC  AND  TECHNICAL 
PROGRAM  (STIP) 

•  ISSUES: 

-  TECHNICAL  INFORMATION  PROGRAM  MANAGEMENT 

-  TECHNICAL  DOCUMENT  PRODUCTION  AND  ACCESS 

-  COMPUTERIZED  INFORMATION  SYSTEMS  AND  DATA  BASES 

-  INFORMATION  TRANSFER  SERVICES  AND  APPLICATIONS 

•  RECOMMENDATIONS. 

-  APPOINT  A  DOO  TECHNICAL  INFORMATION  FOCAL  POINT 

-  CREATE  AN  ADVISORY  COUNCIL  ON  TECHNICAL  INFORMATION 

-  DEVELOP  A  PLAN  TO  SUPPORT  THE  DEFENSE  STIP 

-  DTIC  PROVIDE  A  "OATA  BASE  OF  DATA  BASES” 

-  IMPROVE  CONTRACTOR  ACCESS  TO  MILITARY  PUBLICATIONS 


SUMMARY  OF  COMMENTS  REGARDING  INFORMATION  SYSTEMS  AND  DATA  BASES 

•  INFORMATION  SYSTEMS  MUST  BE  USER  ORIENTED 

•  PERSON  ENTERING  DATA  MUST  BE  RESPONSIBLE  FOR  QUALITY,  QUANTITY, 
AND  TIMELINESS 

•  PROLIFERATION  OF  DATA  BASES  IS  NECESSARY  BECAUSE  OF  THE  WIDE 

1  VARIETY  OF  TOPICS  THAT  NEED  TO  BE  COVERED 

•  INFORMATION  ANALYSIS  CENTERS  (IAC)  CAN  BE  CONSIDERED  AS 
HAVING  A  UNIQUE  CAPABILITY  TO  INTERPRET  DATA  AND  PRESENT 
INFORMATION 

I 

•  TECHNICAL  PROBLEMS  ASSOCIATED  WITH  INTERNETTING  DATA 
BASES  WILL  BE  DIFFICULT  AND  COSTLY  AND  FOR  THE  NEXT  SEVERAL 
YEARS  INTERFACE  TO  THE  DATA  BASES  BY  HUMAN  OPERATORS  WILL 
BE  REQUIRED 
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DOD/INDUSTRY  TECHNICAL  INFORMATION  CONFERENCE 

fi 

7-8  DECEMBER  1982 

• 

•  OBJECTIVE: 

I 

TO  ASSESS  DEFENSE  INDUSTRY'S  REQUIREMENTS  FOR  DOD  TECHNICAL 

AND  MANAGEMENT  PLANNING  INFORMATION 

• 

•  WORKING  SESSION  TOPICS: 

r 

-  INDUSTRY  PERCEPTION  OF  CURRENT  AND  FUTURE  DOD 

SCIENTIFIC  AND  TECHNICAL  INFORMATION  PROGRAMS 

• 

r 

•  TECHNICAL  INFORMATION  AND  PLANNING  REQUIREMENTS 

OF  INDUSTRY 

• 

-  IMPROVING  THE  DOD/INDUSTRY  INFORMATION  EXCHANGE 

PROCESS 

• 

2 

DOD  PERCEPTION/GUIDANCE  REGARDING  DATA  BASE  DISSEMINATION 

• 

1 

•  SEEK  WAYS  TO  SAVE  MONEY  THROUGHOUT  ALL  PHASES  OF  THE 

ACQUISITION  PROCESS 

» 

•  MAINTAIN  AN  ETHICAL  DISTANCE  IN  BUSINESS  RELATIONSHIPS 

BETWEEN  DOD  AND  INDUSTRY  WITHOUT  BECOMING  ADVERSARIAL 

• 

•  MAINTAIN  TECHNICAL  COLLABORATION  WITH  INDUSTRY  TO  ACHIEVE 

MAJOR  SYSTEMS  OBJECTIVES  AND  MEET  TECHNOLOGICAL  CHALLENGES 

• 

•  CREATE  AN  ENVIRONMENT  WHICH  ENCOURAGES  DEVELOPMENT  OF 

INNOVATIVE  CONCEPTS  WHICH  COMPLEMENT  AND  BROADEN 

THE  SPECTRUM  OF  CONCEPTS  DEVELOPED  INTERNALLY  TO  DOD 

• 
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DOD/INDUSTRY  TECHNICAL  INFORMATION  CONFERENCE 
7-8  DECEMBER  1982 

RECOMMENDATIONS 

•  REPLACE  R&D  PLANNING  SUMMARY  (DD-1634)  DATA  BASE  WITH  NEW 
ON-LINE  DATA  BASE 

-  RETAIN  PRESENT  DD-1634  DATA  BASE  ON  LINE  FOR  AT  LEAST  2  YEARS 
TO  MAKE  DATA  AVAILABLE  WHICH  IS  USEFUL  BEYOND  CURRENT  YEAR 

-  ENSURE  THE  NEW  DATA  BASE  IS  SEARCH-COMPATIBLE  WITH  WORK 
UNIT  INFORMATION  SYSEM  AND  TECHNICAL  REPORT  DATA  BASES 

•  EXPAND  INFORMATION  SOURCES  FOR  USE  BY  INDUSTRY 

-  ADD  MORE  DATA  BASES  TO  DEFENSE  RDT&E  ON-LINE  SYSTEM 
(DROLS)  (e  g.,  HOW  TO  GET  IT.  DATA  BASE  OF  DATA  BASES,  ETC). 

•  PROVIDE  ADDITIONAL  INFORMATION  ABOUT  FOREIGN  TECHNOLOGY 
(e.g..  COVERAGE.  ACCESS,  AVAILABILITY  OF  TRANSLATIONS,  ETC). 

•  IMPROVE  ACCESS  TO  INFORMATION  USEFUL  TO  PLANNERS.  REALIZING 
THAT  THE  INFORMATION  MUST  BE  TIMELY,  COMPLETE,  AND  CONTAIN 
PROJECTIONS  FOR  THE  FUTURE 

-  EXPAND  SERVICES  AND  STAFF  AT  TRI-SERVICE  INDUSTRY  INFORMATION 
CENTERS  (TIIC) 

-  EXPAND  COVERAGE  AT  TIICs  TO  INCLUDE  INFORMATION  FROM  OTHER 
DOD  AGENCIES.  AND  PROCUREMENT  PLANNING  DATA  AND  INFORMA¬ 
TION 

-  HAVE  MORE  CONVENIENT  AND  TIMELY  ACCESS  TO  DOCUMENTS  CITED 
IN  RFPs,  (e.g.,  STANDARDS,  SPECIFICATIONS,  FORMS,  ETC) 


RECOMMENDATIONS  (Cont'd 


-  IMPROVE  OROLS  TO  MAKE  SYSTEM  MORE  USER-FRIENDLY  AND  MORE 
RESPONSIVE  TO  SUBSCRIBER 

-  INVESTIGATE  OTHER  METHODS  OF  PROVIDING/HANDLING  DATA,  SUCH 
NETWORKING  AND/OR  GATEWAY  PROGRAMS  AND  SYSTEMS 

-  IMPROVE  THE  PROCEDURES  FOR  RELEASING  LIMITED  DOCUMENTS  TO 
INDUSTRY  AND  IMPROVE  THE  PROCEDURES  FOR  HANDLING  DTIC's 
FORM  55  (REQUEST  FOR  LIMITED  DOCUMENT) 

-  STANDARDIZE  POTENTIAL  CONTRACTOR  PROGRAM  AMONG  DOD  COM 
PONENTS  AND  IMPROVE  ACCESS  OF  POTENTIAL  CONTRACTORS  TO 
NECESSARY  INFORMATION 

ENSURE  CONSISTENCY  AMONG  THE  MILITARY  SERVICES  AND  DOD 

COMPONENTS  WHEN  THEY  INTERPRET  AND  IMPLEMENT  DOD  POLICY, 

DIRECTIVES.  AND  INSTRUCTIONS 

ESTABLISH  BETTER  MEANS  OF  COMMUNICATING  WITH  INDUSTRY 

AND  INDUSTRY  GROUPS 


POD  INFORMATION  FOR  INDUSTRY  COMMITTEE  (IIC) 


•  PURPOSE: 

HELP  FORMULATE  POLICY  AND  GUIDANCE  FOR  THE  EXCHANGE  OF 
DEFENSE  TECHNICAL  AND  PLANNING  INFORMATION 

•  MEMBERS: 


MR.  KARL  BASTRESS  DARCOM 

MR.  WALTER  BLADOS  AFSC 

DR.  PARIS  GENALIS  OUSDRE 

MR.  MARTIN  PEARL  NAVMAT 

MR.  GEORGE  POLLACK  NOSC 

MR.  FRANK  SOBIESZCZK  OUSDRE 

DR.  LEO  YOUNG  OUSDRE 


INDUSTRY  ADVISORY  GROUP 

•  PURPOSE: 

-  HELP  DOD  KEEP  ATTUNED  TO  THE  NEEDS  OF  INDUSTRY 

-  HELP  IN  EFFECTING  THE  EXCHANGE  OF  DEFENSE  INFORMATION 
NEEDED  BY  INDUSTRY 

•  MEMBERS: 


MR.  EARNEST  DEADWYLER 
MS  MARGO  GIARDANO 
MR.  JOHN  KEEHNER 
MS  DIANE  LAFFERMAN 
MR.  FRED  LEWIS 
MS  LUCILLE  MCCLURE 
MR.  NATHAN  MCGREW 


TEXAS  INSTRUMENTS 
HONEYWELL 
GOODYEAR  AEROSPACE 
ROCKWELL  INTERNATIONAL 
HUGHES  AIRCRAFT 
MARTIN  MARIETA  AFROSPACE 
GENERAL  DYNAMICS 


DATA  BASE  DISSEMINATION  SECTION 


PROPOSED  APPROACH 


•  BEGIN  WITH  MANAGEABLE  AND  RECOGNIZED  DATA  BASE 
DISSEMINATION  CHALLENGES 

•  WORK  WITH  EXISTING  COMMITTEES,  USER  GROUPS.  AND 
ADVISORY  GROUPS  TO  SOLVE  RECOGNIZED  PROBLEMS  AND 
IDENTIFY  ADDITIONAL  PROBLEMS 

•  EXPAND  AS  PARTICIPATION  AND  INTEREST  INCREASES. 
STRIVE  TO  SUCCEED  AND  BUILD  ON  SUCCESS 

•  FOCUS  ON  WAYS  TO  IMPROVE  DEFENSE  PRODUCTIVITY 
THROUGH  BETTER  UTILIZATION  OF  DATA  RESOURCES 


PLANS 


•  WORK  WITH  DROLS  USER  COUNCIL  AND  DOD  INFORMATION  FOR 
INDUSTRY  COMMITTEE  TO  SEEK  CONTINUED  DROLS  UPGRADE 

•  SEEK  IMPROVEMENTS  IN  PROCEDURES  FOR  QUALIFIED  CONTRACTORS 
TO  OBTAIN  CLASSIFIED  TERMINAL  INTERFACE  WITH  DTIC  DATA  BASES 

•  SEEK  IMPROVEMENT  IN  ACCESSIBILITY  AND  AVAILABILITY  OF  MILITARY 
PUBLICATIONS  FOR  ALL  USERS 

•  SEEK  TO  IMPROVE  QUALITY  OF  RESEARCH  AND  DEVELOPMENT  PLANNING 
DATA  BASE  AND  DATA  BASE  ACCESS  BY  CONTRACTORS 

•  WORK  WITH  OTHER  TECHNICAL  DOCUMENTATION  SECTIONS  TO  IDENTIFY 
DATA  BASES  IN  USE  ANO  IMPROVE  DISSEMINATION  AND  LINKAGE 


ADPA 

TECHNICAL  DOCUMENTATION  DIVISION 
1984  ANNUAL  MEETING 

Workshop  #1  -  Data  Management 


1.  Attendance;  64  (27  Government  -  42%,  37  Industry  -58%) 

(See  Attachment) 

2.  Intent:  The  intent  of  this  half-day  workshop  was  to  provide  a  forum  for 
attendees  from  Government  and  Industry  having  similar  functional  interests 
and  responsibilities  to  foster  person-to-person  discussions  of  mutual  interest; 
this  dialogue  to  bring  about  increased  awareness  of  current  issues  and 
concerns  being  faced  by  either  and/or  both  sides;  to  promote  greater 
understanding;  to  provide  opportunities  to  enumerate  successes.  In  all  of  the 
above  to  promote  improved  relationships  and,  hopefully,  increased  efficiency 
in  these  function's  contributions  to  our  nation's  defense  preparedness. 

3  Approach:  As  customary,  participants  were  encouraged  to  turn  in  written 
questions  for  discussion.  Thirteen  were  submitted.  In  addition,  invited  short 
presentations  on  selected  current  vital  issues  were  made  by  the  following 
nationally  recognized  professionals: 

Technology  Transfer  to  a  Dual  Source  J.  L.  Remiker 

General  Dynamics 

Al  Signor 
NAVSEA  Systems 

Ray  Calhoun 
Texas  Instruments 

Wally  Rook* 

Cerberonics 

James  Richardson 
DMSSO 

(‘unable  to  attend  -  presentation  made  by  substitute) 

Interestingly,  the  thirteen  submitted  questions  each  fell  into  one  of  the  above 
topics.  The  presentation  and  question/answer  will  be  addressed  together 
below. 

4  Topics/Questions 

a.  Technology  Transfer  to  a  Dual  Source 

Q-l  .."How  much  information  is  involved  in  the  "why's"  of  the  data 
package  -  can  you  itemize  the  manufacturing  information  required?" 

Q-2  .."Who  is  going  to  evaluate  "proprietary  rights"  from  the 
Government  point  of  view7  It  would  take  a  maior  retraining  of  DCAS 
personnel  to  permit  them  to  do  so  " 


Data  Warranties 
Data  Pricing 

Data  Manager  Certification 
DOD  DM  Media/Initiatives 
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Congress  and  DOD  implement  the  proposed  plan  to  obtain  all 
manufacturing  data  as  part  of  the  reprocurement  data  package,  will  we 
not  drive  away  many  small  business  suppliers?" 

Technology  transfer  is  in  essence  a  transfusion  of  information  to  a  second 
source.  In  some  respects  it  approximates  what  some  in  Government  feel  is 
required  of  a  reprocurement  data  package  -  the  second  source  needs  to  be 
able  to  duplicate  the  product  using  the  same  data  package.  This  goes  beyond 
the  traditional  Form,  Fit  or  Function  criteria.  Also  involved  are  the  under¬ 
standing  of  specification  requirements,  test  requirements,  factory  processes  - 
the  whys  and  wherefores.  Tnis  latter  really  becomes  the  essence  of 
accomplishing  a  successful  technology  transfer  to  a  dual  source  The  answer  to 
who  will  evaluate  "proprietary"  (limited)  rights  is  complex  one  and  is  being 
addressed  in  the  new  data  initiatives.  The  Government  expects  that  increasing 
second  source  procurement  will  broaden  rather  than  decrease  the  small 
business  base. 

b.  Data  Warranties 

Q-4..."(1)  What  specific  things  are  warranted  in  a  technical  data  package, 
i.e.  format,  fading,  legibility,  technical  content,  use  by  everyone?  (2)  Do 
you  foresee  a  tie-in  between  hardware  warranties  and  data  warranties’" 

Warranty  of  Technical  Data  was  specified  in  ASPR  7-105. 8(a)  and  made  more 
specific  in  DAR  7-104.9,  which  inserted  clauses  in  bas  ;  regulation  for  firm- 
fixed  price  and  fixed-price  incentive  contracts.  FAR  46.701  thru  46.710 
combines  all  types  of  warranties  into  one  section  of  the  regulation,  defines 
warranties  and  nature  and  use  of  product. 

DAR  7-104.9  states:  Contractor  warrants  that  all  technical  data  furnished 
under  the  contract  will  at  the  time  of  delivery  conform  with  the  specifications 
and  other  requirements  of  the  contract. 

Warranty  period  -  3  years  after  completion  of  delivery,  or  at  a  greater  time 
when  specified  in  the  contract. 

Latent  Defects  -  Defects  discovered  after  delivery  of  data  will  be  remedied  by 
the  Contractor. 

Government  may  elect  to: 

(1)  Have  Contractor  correct  or  replace  ,  or 

(2)  Correct  and  realize  an  adjustment  in  price  or  fee 

The  matter  of  data  warranties,  including  the  extent  and  manner  of  assessing 
compliance  is  not  throughly  understood  It  would  be  expected  that  (similar  to 
the  close  tie-in  of  the  procurement  data  package  to  the  cost  of  spare  parts)  the 
application  of  performance  warranties  in  DOD  procured  system/components 
would  include  both  hardware  and  data.  The  extent  and  exact  nature  of  tie-in 
are  subject  to  question 


c.  Data  Pricing 


Q-5..."0ur  Program  Office  never  uses  the  data  prices  we  are  required  to 
prepare  and  submit  -  do  you  foresee  the  time  when  this  information  will 
not  be  required?" 

Both  Industry  and  Government  representives  complain  about  inconsistencies 
in  data  costs.  The  same  requirements  can  result  in  "apparant"  bid  variations 
of  twenty-to-one  among  offerers.  Software  costs  offer  similar  frustrations 
Yet,  data  has  been  estimated  to  be  30%  of  system  acquisition  cost,  60%  of 
spares  cost  and  90%  of  R&D  contract  costs.  It  was  reported  that,  per  P.L.  96- 
SI  1  requirements,  the  cost  of  data  directly  attributable  to  the  DID's  contained 
in  the  AMSDL  is  in  the  neighborhood  of  1 37  billion  man/hours.  Variation  in 
data  costs  are  reported  to  result  from  differences  in  business  procedures, 
differences  in  accounting  systems,  differences  in  preparation  methods  and 
others.  The  Data  Price  Group  system  further  fosters  inconsistency. 

Basically,  however,  data  costs  are  made  up  of  a  triad  -  Creation  (cost  of 
creating,  generating,  inventing  and/or  requiring  information);  Preparation 
(cost  of  preparing  the  data  item,  draft  generation,  editing,  illustrating, 
keyboarding,  proofreading,  etc  );  and  Dissemination  (cost  of  reproducing, 
distributing,  maintaining,  storing). 

Again,  the  data  price  groups  are  subject  to  wide  interpretation.  But  in  all 
instances  the  basic  cost  has  not  changed;  it  still  must  be  created,  prepared  and 
disseminated.  The  only  thing  that  changes  is  how  much  of  the  cost  is 
separately  revealed. 

No  one  is  prepared  to  predict  how  long  these  inconsistencies  will  be 
continued. 

d.  Data  Manager  Certification 

Q-6...''What  is  (the)  qualification  to  be  certified  as  a  Data  Manager7" 

0-7...  "Are  there  sufficient  people  involved  in  Data  Management  to 
justify  an  organization  devoted  to  Data  Managers,  hence  DM 
Certification7" 

Q-8  ..''It  was  my  understanding  that  those  members  present  at  (the)  1983 
ADPA  Technical  Document  meeting  voted  for  certification  and  a 
definition  was  arrived  at  during  the  same  meeting.  The  only  problem 
remaining  was  affiliation.  Is  that  not  true  and  what  are  we  doing  or 
need  to  do7" 

The  stated  concept  was  to  develop  a  certification  program  for  Government 
and  Industry  Data  Managers  (a)  to  promote  the  recognition  of  professionalism 
in  the  discipline  (function)  and  (b)  to  attest  to  the  qualifications  and  individual 
achievement  through  experience  and  the  successful  completion  of  a  nationally 
recognized  program. 

One  obstacle  has  been  identifying  a  willing  sponsor  (organization)  -  still 
unachieved.  Another  problem  emphasized  atthe  1983  Annual  Meeting  was 
an  expressed  need  to  standardize  on  the  function  definition  before  proceding 
further  A  sub  committee  was  established  and  met  later  on  in  1983  to  address 
this  orobiem  but  was  unable  to  comolete  it. 


Workshop  participants  expressed  a  fervent  desire  to  continue  to  pursue  this 
effort,  recognizing  that  the  function  definition  problem  can  readily  be 
handled  via  a  step-certification  process  similar  to  certifications  in  other  fields 
The  r  nounced  decision  to  continue  this  sub-committee  task  requires  the 
voluntary  identification  of  interested  active  participants  who  will  direct  their 
efforts  toward  establishing  specific  criteria  for  certification.  Some  feel  a 
DM/CM  certification  is  perferred. 

e.  DOD  DM  Initiatives/Media 

Q-9... "During  the  1982  workshop  it  was  indicated  that  Herb  Atkins  was  in 
the  process  of  developing  a  standard  set  of  abbeviations  for  use  on 
automated  DD1423,  or  data  tracking  tools.  I  have  been  waiting  two 
years  for  a  report.  What  is  the  status  of  this  effort?" 

0-10. .."During  1982, 1  addressed  a  letter  to  DMSSO  (Vince  Mayolo).  In 
the  letter,  i  made  a  couple  of  possible  recommendations  to  the  DD1423 
DMSSO  responded  that  my  comments  were  worthy  of  consideration  and 
that  an  effort  to  review  the  DD1423  would  take  place  in  late  1982/early 
1983.  Did  the  meeting  take  place’  What,  if  anything,  resulted’" 

Q- 1 1 ..."  I  understand  that  El  A  is  in  the  process  of  developing  a  data 
management  specification  or  standard  Would  it  be  possible  for  ADPA 
and  EIA  to  work  together  to  develop  the  Industry  data  management 
specification  or  standard?  Once  developed,  it  could  serve  as  the  basis  for 
a  joint  ADPA/EIA  effort  covering  DM  certification  using  the  Industry  DM 
specification  or  standard  as  the  foundation." 


0-1 2. .."Since  there  is  no  MIL-STD  on  Data  Management,  there  has  been 
difficulty  in  justifying  the  importance  of  the  DM  function;  if  technical 
manuals  are  removed  from  DM  control  is  there  any  future  for  DM 
personnel?" 

0-1 3... "Explain  the  inconsistency  in  the  Government  documents  -  where 
DAR  does  not  recognize  "Proprietary  Rights"  but  DODD  5400  7  does  -  for 
a  wide  variety  of  reasons  " 

The  DOD  near-term  DM  initiatives  resulting  from  the  new  laws  and  DAR 

Supplement  6  (on  Spares  Procurement)  are: 

•  Increased  application  of  MIL-STD-789C,  Procurement  Coding,  Spare  Parts  -  - 
Requires  a  detailed  listing  of  each  item  of  data 

•  Increased  application  of  MIL-STD-885  Reprocurement  Data  Package  -  -  -much 
greater  emphasis 

•  Increased  emphasis  on  contractor  data  management.  More  quality  controls 
on  accuracy  and  completeness  of  data  package.  More  quality  controls  on 
application  and  working  of  Rights  in  Data.  Availability  of  documentation  to 
justify  limited  rights  claims. 

•  From  the  above,  expect  Data  Manager  responsibility  to  increase  dramati¬ 
cally 


Need  for  media  revision: 


MIL-STD-963  (out  this  summer  for  review  (comments)) 

DOD- 5010.12 

DOD  5000. 19L  enclosure  V 

All  Government  agencies  need  to  consolidate  forms  (e.g.  1423, 
1664) 

DD1423  revision  March  1984  -  late  DID  Data  Base  for  all  Federal 
Agencies? 

Many  report  problems  getting  Data  Manager  into  contract  negotiations. 

Feels  that  DM  function  won't  really  be  impacted  by  taking  Technical  Manuals 
off  of  CDRL. 

There  is  still  time  to  make  recommendations  to  DMSSO  on  improvements  to 
DD1423 

EIA  has  been  developing  a  DM  Guide,  but  not  issued  yet.  No  precedence  for 
but  probably  could  be  a  joint  issue  if  pursued. 

With  all  the  changes  in  media  underway,  some  feel  the  need  for  some  training 
effort  (dog  &  pony  show)  to  bring  everyone  up  to  speed.  Suggestion  that  an 
overview  of  such  and  effort  be  provided  at  next  year's  annual  meeting. 


John  R.  Hart, 
Chairman 
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NAME 

ORGANIZATION 

MAILING  ADDRESS 

AND  PHONE 

John  R.  Hart 

Boeing  Aerospace 

P.  0.  Box  3999  M/S8K-61 

Seattle,  WA  98124 
(206)  773-1935 

James  L.  Remiker 

General  Dynamics/Convair  Div. 

P.  0.  Box  85357,  MZ23-6060 

San  Diego,  CA  92138 
(619)  573-8588 

Joe  Meredith 

Newport  News  Shipbuilding 

4101  Washington  Ave 

Newport  News,  VA  23607 
(804)  380-7939 

Kent  M.  Taylor 

AT&T  Technologies 

2400  Reynolda  Road 
Winston-Salem,  NC  27106 

D  L.  Smock 

NAVSVRWEPCEN 

White  Oak  Lab 

Silver  Spring,  MD  20910 

Code  E34 

James  Preston 

Tenneco  Inc. 

P.  O.  Box  2511 

Houston,  TX  77001 
(713)  757-4848 

Pat  Greenwood 

Hercules  Inc. 

P.  O  Box  98 

Magna  UT  84044 
(801)  250-5911 

Susie  Mendiola 

Kelly  AFB 

127  E.  Mistletoe 

San  Antonio,  TX  78212 

AV  945-831 

Miriam  S.  Jones 

Robins  AFB 

MMMR 

Robins  AFB,  GA 

AV  468-2833 

Emil  A.  Melillo 

ITTDCD 

492  River  Road 

Nutley,  NJ 
(201)  284-3659 

Bruce  F.  Ogden 

FAI 

1593213  Shady  Grove  Rd 
Gaithersburg,  MD  20877 
(301)  258-5130 

Joy  L.  Viars 

Designers  &  Planners,  Inc. 

1725  Jefferson  Davis  Hgwy 

Suite  700 

Arlington,  VA  22202 
(703)  892-8200 
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NAME 

ORGANIZATION 

MAILING  AOORESS 
AND  PHONE 

Jean  L.  Harman 

Naval  Sea  Systems 
Command 

NAVSEA  (SEA  55Z3) 
Washington  DC  20362 
(202)692-0160 

Gaetano  C.  Grande 

Ragtheon  Company 

Missile  Systems  Div. 

Ml 3-34,  Hartwell  Rd. 
Bedford,  Mass.  01730 
(617)  274-7100X2707 

E.  A.  Woodward 

Honeywell 

Marine  Systems  Div 

5303  Shilshole  Ave. 

N.W. 

98107 

(206)789-2000x1615) 

R.  B.  Jordan 

USATACOM 

DRSTA-TS 

Warren,  Mich  98090 
(313)  574-8818 

AV786-88 18/8796 

Darlene  Duerden 

Belvoir  R&D  Center 

Attn:  STRBE-DE 

Ft.  Belvoir,  V A  22060 
(703)664-5128 

AV  354-5128 

Joseph  J.  Adamo 

USATACOM 

DRCPM-TV-EL 

Warren,  Ml  48090 
(313)  574-6713 

AV  786-67 13 

James  Richardson 

OUSD  (R&E)  DMSSO 

5203  Leesburg  Pike 

Falls,  Church,  VA  22041 
(202)756-2342 

A.  D.  Signor 

NAVSEASYSCOM 

NSWSES  Code  4330 

Port  Hueneme,  CA 

93043 

(805)982-5844 

Dr.  Ray  Calhoun 

Texas  Instruments 

Mail  Sta.  333 

13500  N.  Central 
Expressway 

Dallas,  TX  75266 
(214)867-9683 

R.  1.  Travis 

Martin  Marietta 
Aerospace 

454  School  Street 
Washington,  DC 

646-2190 

John  Hornick 

U  S.  Army 

HQ  AMCCOM 
DRSMC-LET-C 

Rock  Island  III.  61299 
(309)  794-5305 
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Hal  Rowland 

Sundstrand  Aviation 

4747  Harrison  Ave 
Rockford,  IL  61 101 
(815)  226-7445 

Curtis  L.  Davis,  Jr. 

Rolm  Corp.  MSC  Div. 

1  River  Oaks  Place 

San  Jose,  CA  95134 
(408)  942-5847 

Michael  Hum 

Texas  Instruments 

P.  0.  Box  226015 

Mail  Sta.  306 

Dallas,  Texas  75266 
(214)  867-9787 

Norm  Kinder 

Boeing  Aerospace  Co. 

P.  O.  Box  3999 

M/S8C-53 

Seattle,  WA  98124 
(206)  773-0297 

Gig  Sagahon 

Northrop  Co. 

1800  Washington  Blvd 
Pico  Rivera,  CA 
90660-3737 
(213)942-6605 

Edward  R.  McIntyre 

DoD 

DIR  NSA  Attn:  5522 

Ft.  G.  Meade,  MD  20755 
(301)688-6871 

William  L.  Smithson 

DoD 

US  Army  Missile 
Command,  Tech  Data 
Mgtmt  Div  -  Sys  Eng  & 
Prod  Dir  DRSMI-EDC 
Redstone  Arsennal, 
Alabama  35898 
(205)  876-2586 

David  B.  Ells 

Martin  Marietta 

P.  O  Box  179 

Denver,  Colorado  80201 
(303)  477-7783 

Richard  B.  Heggem 

Westinghouse 

Marine  Division 

P.  O.  Box  499  (EW-1) 
Sunnyvale,  CA  94088 

Charles  A.  Cattaneo 

Martin  Marietta 

P.  O.  Box  5837  (MP-33) 
Orlando,  FL32855 
(305)  356-2395 

Patricia  Giles 

DoD 

DIRNSA  Attn:  R183 

9800  Savage  Rd 

Ft.  Meade,  MD 
(301)859-6706 
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Dennis  R.  Motta 

Texas  Instruments 

P  O.  Box  226015  M/S 

333 

Dallas,  TX  75266 
(214)867-9917 

Tony  Darmanin 

i 

General  Motors  of 
Canada  Ltd. 

Diesel  Division 

P.  0.  Box  5160 

London,  Ontario, 

Canada 

(519)452-5533 

Vince  Scheno 

US  Army  AMCCOM, 

CRDC 

DRSMC-TSC-E  (A) 
Aberdeen  Prvng  Grnd, 

MD  21010 
(301)  671-3306 

AV  584-3306 

Ronald  J.  Schrage 

ASD/XRJ 

Wright-Patterson 

AFB,  OH  45433 
(513)  255-6651 

Richard  Thomas 

FMCCorp. 

Box  32682 

San  Jose,  CA  95152 
(408)  289-3973 

C.  E.  Tiedemann 

McDonnell  Douglas 
Astronautics 

Box  516 

Lambert  Field 

St.  Louis,  MO  63166 
(314)  232-5395 

Roger  P.  Frazier 

NAVPRO  Dallas 

P.  O.  Box  225907 

Dallas,  TX  75265 
(214)  266-3115 

Shirley  A.  Rudduck 

ASD/AWZ 

Wright  patterson 

AFB,  OH  45433 
(513)  255-2678 

AV  785-2678 

Beecher W.  Vaughn 

ASD/AEC 

Wright  Patterson 

AFB,  OH  45433 
(513)  255-2419 

AV  785-2419 

E.  Donald  Hartzell 

DoD 

DIRNSA  Attn:  S523 

Ft.  George,  G.  Meade, 

MD  20755 
(301)  688-7181 

AV  235-7181 
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Jerome  J.  Cichowicz 

Army 

Commander  CRDC 
DRSMC-CLT-I  (A) 
Aberdeen  Proving 
Ground,  MD  21010 
(301) 671-4102 

AV  584-671  102 

Bob  R.  Ramsey 

Ford  Aerospace 

Ford  Road 

Newport  Beach,  CA 

92660 

(714)  720-6592 

John  A.  Shasteen 

Honeywell  Avionics 

13350  US  Hy  19 
Clearwater,  FL  33516 
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A  PEEK  AT  REASONS  FOR  INCONSISTENT  DATA  COSTS 


Dr.  Ray  Calhoun 
Texas  Instruments 


SUMMARY 


Both  Government  and  industry  ccmplain  about  inconsistencies  in  data/docu¬ 
mentation  costs  yet  both  share  in  a  system  which  fosters  inconsistencies. 

Both  routinely  engage  in  crusades  to  reduce  the  cost  of  ’’paper."  Unfortunately, 
what  emerges  is  a  system  (involving  both  Government  and  industry)  that  clouds 
rather  than  recognizes  (or  reduces)  costs  of  information.  Often,  the  data 
requirements  are  poorly  defined.  Even  when  given  the  same  requirements, 
bidders  responses  exhibit  wide  variations.  Same  apparently  "give  away”  data, 
while  others  are  accused  of  "overpricing.”  Initially  accurate  estimates  become 
changed  and  distorted  during  review,  costing,  and  contracting  processes. 

Because  they  are  subject  to  wide  interpretation,  the  four  DoD  data  price 
groups  foster  inconsistencies.  Inconsistencies  also  can  occur  because  of 
Department  of  Defense  policies  which  require  line  item  costing  also  allow 
rolling  up  individual  data  item  costs  into  program  effort.  By  making  data 
effort  "part  of  the  equipment  (POE)"  or  Not  Separately  Priced  (NSP),"  data 
costs  become  obscured  because  they  are  incorporated  into  total  program  effort. 

The  key  to  consistency  is  to  recognize  that  the  basic  cost  of  information 
does  not  change  a  great  deal;  what  changes,  under  present  practices,  is  how 
much  of  the  cost  is  separately  revealed. 

Information  (data)  is  a  product.  It  takes  many  forms.  The  data  effort 
represents  a  large  (some  say  30  percent  or  more)  part  of  program  costs  and  may 
be  increasing  because  the  ratio  of  software  to  hardware  is  changing.  Software 
(which  means  more  data  effort)  may  soon  exceed  hardware  costs. 

Information  is  composed  of  the  triad  of  creation,  preparation,  and 
dissemination.  To  reduce  inconsistencies,  we  must  develop  a  costing  system  to 
address  all  three  facets  of  the  information  triad.  Only  then  can  we 
realistically  approach  the  issue  of  data  cost  effectiveness. 
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Both  Government  and  Industry  representatives  complain  about  inconsistencies 
in  data/documentation  costs  yet  both  share  in  the  systan  which  fosters  incon¬ 
sistencies.  For  example,  an  Electronic  Industries  Association  study  panel  on 
data  costs  and  data  pricing  noted  that  data  pricing  has  long  been  a  problem 
for  both  the  contractor  and  the  Government.  The  task  of  this  panel  (which 
included  members  representing  both  industry  and  Government)  was  to  study  the 
pricing  issue  and  recommend  a  consistent  approach  to  the  pricing  of  data.  An 
example  they  used  was  a  matrix  comparing  the  bid  prices  of  five  contractors 
(on  the  same  proposed  procurement)  for  five  technical  publications  data  items. 
Although  the  requirements  were  the  same  for  all  bidders,  the  responses  ranged 
from  a  few  thousand  dollars  to  over  two-hundred  thousand  dollars  for  the  same 
item- -over  a  twenty- to-one  variation!  After  four  days  of  work,  panel  members 
had  identified  some  major  factors  affecting  price  inconsistencies.  Among  the 
possibilities  considered  were  either  to  place  creation  costs  into  the  data 
effort  (together  with  the  preparation  and  dissemination  costs)  or  to  place 
preparation  and  dissemination  costs  into  Statement  of  Work  (SOW)  effort  so 
that  all  three  facets  of  the  information  cost  triad  could  be  considered. 
However,  complexities  of  the  issues  were  such  that  the  panel  members  were 
unable  to  make  any  recommendations  and  they  referred  the  problem  back  to  EIA 
for  further  consideration.1  The  EIA  panel's  experiences  offer  but  one  example 
of  the  frustrations  of  trying  to  come  to  grips  with  the  problems  of  data  cost 
inconsistencies.  Software  data  inconsistencies  offer  similar  frustrations. 
Another  EIA  group,  the  subcommittee  on  Software  Cost  Estimating  also  addressed 
similar  issues. 2 


Data,  according  to  the  Defense  Acquisition  Regulations  (DAR)  means: 
"Recorded  information,  regardless  of  form  or  characteristic,”  DAR  1-201.35. 
Some  say  we  have  been  swamped  by  "paper"  costs.  Industry  and  Government 
managers  find  themselves  ill-equipped  to  deal  with  paper.  Parkinson  wryly 
observes,  "...paper  has  a  tendency  to  breed  and  multiply. ”3 


^his  group  was  anpaneled  at  the  16th  Annual  Workshop  of  the  G-33  Committee 
on  Computer  Resources,  Data  Management,  and  Configuration  Management  (EIA)  held 
20-24  September  1982,  Dallas,  Texas. 

2  The  Software  Cost  Estimating  subccrrmittee  is  a  working  group  of  the 
17th  Annual  Workshop  of  the  G33  Ccmittee  on  Data  and  Configuration  Management 
and  the  G34  Committee  on  Computer  Resources  (EIA)  which  met  19-23  September 
1983,  Phoeniz,  Arizona. 

3  C.  Northcote  Parkinson,  "Parkinson  on  Paperwork,"  Modern  Management: 
Issues  and  Ideas,  ed.  David  R.  Hanpton  (Belmont,  CA.:  Dickenson  Publishing 
Company,  Inc.,  1969),  p.  218. 
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According  to  Feeley,  "The  chief  problem  with  data  pricing  today  is  the 
lack  of  interest  and  knowledge  of  data  on  the  part  of  most  Government  Con¬ 
tracting  Officers. "4  Industry  program  managers  also  appear  to  suffer  from 
the  same  problem  -  lack  of  interest  and  knowledge.  "Paper”  is  often  viewed  as 
a  program  manager’s  nemesisj  a  problem  at  worst,  a  nuisance  at  best. 

A  challenge  faces  both  contractors  and  Government  procuring  activities 
to  acquire  the  needed  data  without  it  appearing  that  "all  that  money”  is  being 
spent  for  "paperwork.”  Accordingly,  inconsistencies  develop.  By  making  data 
effort  "part  of  the  equipment  (POE)”  or  Not  Separately  Priced  (NSP),”  data  costs 
are  rolled  up  into  total  program  effort  which  makes  inconsistencies  more 
difficult  to  see.  Several  reasons  influencing  inconsistencies  come  to  mind. 

(1)  Dislike  for  paperwork  stemming  from  the  undesirable  connotation  given 
by  our  society. 

(2)  Policies  -  unofficial  and  official. 

(3)  Budget  and/or  organizational  pressures. 

(4)  Designers  that  do  not  wish  to  be  bothered  by  paper. 

(5)  Being  unable  or  unwilling  to  discretely  define  the  "data"  in  a  way  that 
can  be  costed.  Or,  parenthetically,  unable  to  do  anything  with  the  unfortunate 
(albeit  well-intentioned)  definition  of  the  data  which  is  to  be  costed. 

(6)  An  educational  system  that  too  often  foregoes  ccmmuni cat ions  skills 
training  and  thus  produces  individuals  that  are  ill  prepared  to  deal  with  the 
documentation  aspects  of  real-world  programs. 

(7)  A  negotiating  tactic  whereby  the  objective  is  to  induce  discussion 
over  data  items,  thereby  lessening  attention  to  other  items. 

(8)  A  contractor  marketing  tactic  where  data  is  offered  as  a  "lagniappe." 

What  are  some  official  explanations  of  causes  of  inconsistencies?  Clause 
OAR  3.814(b)  lists  the  following  causes. 

(i)  Differences  in  business  practices  in  competitive  situations 

(ii)  Differences  in  accounting  systems  among  offerers 

(iii)  Use  of  factors  or  rates  on  some  portion  of  the  data 

(iv)  Application  of  common  effort  to  two  or  more  data  items 

(v)  Differences  in  data  preparation  methods  among  offerers. 

Another  factor  fostering  inconsistencies  is  the  ’’over  and  above"  concept 
embodied  in  the  four  data  price  groups,  which  are  subject  to  widely  varying 
interpretations.  Hence,  use  of  the  Department  of  Defense  (DoD)  price  groups 
can  foster  cost  inconsistencies.  The  question  isn't  one  of  do  we  want  to  know 
the  cost  of  data,  but  rather  one  of  how  much,  if  any,  of  the  cost  of  data  do  we 
wish  to  show? 


^Charles  R.  Feeley,  The  Vital  Link:  Understanding  Contractor  Acquired  Data, 
(Charles  R.  Feeley,  1981),  p.  7-15. 
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Three  major  areas  form  the  data  cost  triad: 

(1)  Cost  of  creating,  generating,  inventing,  and/or  acquiring  information. 

(2)  Cost  of  preparing  the  data  item,  such  as  draft  generation,  editing, 
keyboarding,  illustrating,  proofreading,  etc. 

(3)  Cost  of  reproducing,  distributing,  and  preserving  the  data  item. 

Additionally,  the  cost  of  maintaining  and  updating  data  items  may  be 
considered.  Verification  and  validation  costs  also  may  impact  some  items. 

However,  the  three  primary  areas  are  creation,  preparation,  and  dissemination . 

With  a  Group  I  data  item  (an  itan  prepared  only  because  of  user  require¬ 
ments),  we  may  see  all  three  major  costs  (creation,  preparation,  and  reproduc¬ 
tion/distribution).  With  a  Group  II  data  item  (an  item  that  requires  additional 
effort  to  meet  user  requirements),  we  may  see  only  the  cost  of  preparation  and 
reproduction/distribution.  With  a  Group  III  data  item  (where  the  data  exists 
but  the  item  must  be  copied)  we  supposedly  see  only  reproduction/distribution 
costs.  Group  IV  data  items  (those  prepared  in  the  regular  course  of  a  commercial 
venture)  are  supplied  at  no  charge {  but  they  cost  -  nothing  is  free. 

The  data  price  groups  are  subject  to  wide  interpretation,  but  in  all  in¬ 
stances  the  basic  cost  of  information  has  not  changed;  it  still  must  be  created, 
prepared,  and  disseminated.  The  only  thing  that  changes  is  how  much  of  the  cost 
is  separately  revealed. 

No-cost  or  law-cost  data  appears  highly  desirable.  Cost  reduction  is  con¬ 
sidered  desirable,  but  one  must  remember  that  when  cost  truly  is  reduced  to  zero, 
no  work  is  performed.  The  cost  of  information  produced  in  the  ordinary  opera¬ 
tions  of  an  entity  (which  under  the  present  over  and  above  DoD  guidelines  would 
be  Group  IV  data)  ultimately  is  borne  by  the  user  just  the  same  as  the  cost  of  a 
Group  I  data  item  is  borne  by  the  user.  In  the  first  instance,  the  cost  is 
incorporated  into  the  expenses  of  the  entity  and  is  factored  into  the  cost  of 
whatever  goods  or  services  the  entity  produces.  In  the  second  instance,  the 
cost  is  separately  identified. 

Seme  among  us  say  that  cost  consistency  equates  with  cost  savings.  This  is 
not  necessarily  so  because  consistency  in  costing  does  not  mean  lower  (or  higher) 
costs;  it  only  means  that  costs  are  identified  and  presented  similarly.  For 
example,  perhaps  because  of  policy  influences,  lack  of  knowledge  or  interest, 
procuring  activity  strategy,  or  as  a  marketing  tactic,  seme  contractors  appear 
to  "give  away"  the  data,  a  practice  which  fosters  inconsistencies.  However, 
the  total  program  cost  may  be  realistic  because  the  bottom  line  question  of, 

"Can  I  do  this  job  (including  the  data)  for  this  much?”  must  be  answered. 

Sane  have  said  that  even  with  all  of  the  data  costing  inconsistencies, 
data  costs  are  small  when  compared  to  other  program  costs.  Once  this  might  have 
been  true.  Presently,  if  one  could  see  through  the  veil  of  inconsistency 
and  speculate  on  real  costs,  a  hypothesis  that  information  costs  represent  some 
10  to  30  percent  of  total  project  value  seans  supportable.  Feeley  claims,  "...the 
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data  ’bite’  has  grown  to  up  to  30  percent  of  total  RDT8E  costs. ”5  According 
to  Walton:  "More  than  half  of  every  dollar  spent  in  research  and  development 
is  expended  for  data  efforts  of  researching,  writing,  reading,  listening, 
talking,  and  processing  records. Percentages  can  be  misleading  in  terms  of 
dollars.  A  50  percent  data  cost  on  a  $100,000  Research  and  Development  (R  8  0) 
study  program  would  be  $50,000,  still  a  relatively  small  dollar  cost.  A  10 
percent  data  cost  on  a  $100,000,000  production  procurement  would  be  $10,000,000 
-  an  amount  that  represents  a  significant  sum  although  the  data  percentage  is 
modest.  The  present  estimate  of  data  as  10  to  30  percent  of  contract  value 
may  be  a  increasing  because  the  ratio  of  software  to  hardware  is  changing. 
•Software  development  and  maintenance  costs  are  representing  a  larger  portion 
of  total  project  costs  than  in  times  past  (and  ratio  of  software  to  hardware 
continues  to  increase) .  Sue  Segelke  presents  charts  showing  the  ratio  of 
hardware  to  software  costs  and  DoO  hardware/ software  cost  trends  that  indicate 
software  costs  may  soon  exceed  hardware  costs. ^  Rather  than  face  the  costs  of 
developing  new  systems,  new  applications  for  existing  systems  are  being 
developed  through  software.  Changing  needs  can  be  addressed  through  new  soft¬ 
ware  rather  than  new  hardware.  More  software  means  more  data  effort.  If  data 
costs  are  considered  to  be  the  cost  of  information  a  new  view  emerges. 
Information  is  the  product  being  procured  and  it  still  may  be  a  bargain. 

Another  view  is  expressed  by  Vince  Mayolo,  formerly  of  the  Defense  Material 
Specifications  and  Standards  Office  (DMSSD),  who  claims  that  the  real  cost 
drivers  are  the  requirements  which  cause  data  items  to  be  generated.  By  care¬ 
fully  defining  the  requirements,  data  costs,  in  turn,  can  be  influenced. 

Others  say  that  some  data  items  (for  example,  instruction  manuals)  create 
their  own  requirements  because  such  items  are  needed  to  operate  and  maintain 
equipment  regardless  of  the  type  of  equipment  being  procured.  However,  no 
matter  what  position  is  taken  regarding  cost  drivers,  inconsistencies  magnify 
cost  differences.  Another  point,  often  overlooked,  is  that  acquisition  costs 
represent  only  some  25  percent  of  the  cost  to  the  user  over  the  life  of  the 
item;  some  75  percent  of  cost  is  incurred  after  the  user  receives  the  item  (a 
lesson  in  life-cycle  costs  often  not  noticed  by  contractors).  Standardization 
becomes  important  when  viewing  procurements  over  the  long  term.  In  the  short 
term,  consistency  begins  with  the  procurement/ estimating/ costing  process. 


%eeley.  The  Vital  Link,  p.  7-16. 

^Thomas  F.  Walton,  Communications  and  Data  Management  (New  York: 

John  Wiley  8  Sons,  1976),  p.  19. 

'’Sue  Segelke,  "Ada:  An  Investment  in  the  Future,"  pp.  30-35,  Figures  1, 
2,  and  3,  EG  Engineering  Journal,  September-October  1983,  Texas  Instruments 
Incorporated,  Dallas,  Texas. 
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Ounn  (1967)  foresaw  some  of  the  underlying  factors  affecting  data  costs. 

An  exponential  increase  in  the  amount  and  complexity  of  data. 

Tremendous  advances  in  information  and  storage  techniques.  A 
gradual  change  in  the  nature  of  information  presentation  as  we  move 
from  hard-copy  data  to  machine  processing.® 

The  magnitude  of  the  task  imposed  upon  data  is  great.  There  is  nothing  new 
about  this  situation  either;  Connell  (1967)  observed: 

Equipment  has  been  drastically  reduced  in  size  while  the  amount  of 
supporting  data  has  remained  about  the  same,  depending  upon  maintenance 
concepts,  and  the  reporting  and  control  documentation  has  increased  in 
volume  and  complexity.  Complexity  and  function,  not  size  or  packaging, 
are  determining  factors.  Size  and  packaging  comparisons  have  caused 
data  to  be  accused  of  not  keeping  pace  with  advances  in  equipment. 

This  is  part  of  the  erroneous  picture  of  data.  Remember,  data  is  the 
link  between  man  and  equipment  and  advancing  equipment  without  ad¬ 
vancing  man  only  increases  the  magnitude  of  the  task  imposed  on  data. 9 

John  R.  Hart  looks  at  data  sacred  cows  and  notes  five  contributing  factors: 
(a)  much  too  much  data,  (b)  the  expensive  delivery  system,  (c)  cumbersome 
requirements  definition,  (d)  costly  contract  rigidity,  and  (e)  ineffective 
management  controls For  example.  Hart  says  that  commercial  purchasers 
of  aircraft  spend  much  less  for  documentation  than  military  purchasers  of  the 
same  type  of  aircraft.  He  asks,  "Why  doesn't  the  commercial  world  require 
all  that  data?  The  commercial  world  buys  the  best  product  at  the  best  price, 
with  the  best  service..."11  He  says  that  this  extra  body  of  data  does  nothing 
toward  obtaining  a  better  product,  nor  causing  the  product  to  be  built  cheaper 
or  sooner. 

INFORMATION  is  what  is  procured,  not  "paper."  ANY  INFORMATION  IN  ANY  MEDIA 
becomes  the  primary  concept.  The  computer  revolution  may  well  cause  much 
"paper”  to  became  obsolete.  The  centuries-old  use  of  paper  as  a  medium  to 
store  and  exchange  information  is  being  challenged  by  the  use  of  other  (pri¬ 
marily  electronic)  media  to  handle  information.  Page  counts  can  be  misleading. 

®Qon  W.  Dunn,  "Lessons  Learned  from  Apollo  Data  Management  Pro- 
grems,"  p.  6,  Proceedings,  14th  International  Technical  Communications 
Conference,  Chicago,  May  24-27,  1967,  Society  of  Technical  Writers  and 
Publishers,  (now  the  Society  for  Technical  Communication). 

^A.  0.  Connell,  "Management  of  Subcontractor  Data  in  the  Systems  Engineer¬ 
ing  Process,”  Proceedings ,  14th  International  Technical  Communications  Confer¬ 
ence,  Chicago,  May  24-27,  1967,  Society  of  Technical  Writers  and  Publishers, 
(now  Society  for  Technical  Communication),  p.  4. 

’'Ojohn  R.  Hart,  ’’Continuing  Data  Management  Excess  (or  Feeding  the  Hungry 
Sacred  Cows)"  Proceedings ,  Twenty-Fourth  Annual  Meeting,  24-27  May  1982, 
Technical  Documentation  Division,  American  Defense  Preparedness  Association, 

San  Diego,  CA.  (Washington,  D.C.:  ADPA  1982),  p.  1-1. 

1 1 1bid,  p.  1-3. 
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Too  often  we  have  tended  to  concentrate  on  the  cost  of  the  page  rather  than 
the  cost  on  information  contained  on  the  page 

The  cost  of  developing  information  is  much  greater  than  the  cost  of  dissem¬ 
ination.  The  writer's  anpirical  formula  states  that  50  percent  of  the  cost  is 
involved  in  developing  information,  25  percent  in  preparing  information,  and 
25  percent  in  reproducing/distributing  information.  Feeley  says  that  Govern¬ 
ment  interpretations  of  70-80  percent  for  information  development  [which  in¬ 
cludes  preparation  effort],  and  20-30  percent  for  reproduction/distribution 

are  common. ^ 2 

Now  that  we  have  said  that  INFORMATION  is  what  is  being  procured  and  we 
have  discussed  reasons  for  inconsistency,  what  can  be  done  to  enhance  cost 
consistency?  The  following  considerations  help  develop  cost  consistency. 

(1)  Consistency  begins  with  the  procurement  package.  A  well-developed 
procurement  package  makes  estimating  easier  even  with  the  costing  systsn  in¬ 
consistencies. 

(2)  Believe  your  estimate.  We  are  excellent  estimators  but  poor  believers. 
It’s  a  painful  cliche’  to  say  that  we  cut  the  estimate  by  an  amount  that  even¬ 
tually  turns  out  to  be  an  overrun  or  writeoff. 

(3)  Strive  for  internal  consistency.  If  separate  organizational  entities 
of  a  company  bid  different  portions  of  a  procurement  (such  as  one  bidding  a 
radar  and  another  an  electro-optical  viewing  set)  which  are  part  of  the  same 
weapons  systsn  (and  each  subsystem  has  a  similar  contractor  data  requirements 
list),  the  cognizant  data  estimators  should  coordinate  and  communicate  enough 
to  take  similar  approaches  to  the  CORL  so  that  the  data  responses  at  least 
look  like  they  came  from  the  same  company. 

(4)  Avoid  the  pitfall  of  the  "free"  typist  (or  free  anything).  It  goes 
this  way.  If  I  have  my  document  keyboarded  by  a  secretary  (who  is  indirect 
and  doesn't  charge  effort  to  my  data  cost  account)  it  costs  me  nothing.  How¬ 
ever,  because  effort  is  expended  a  cost  is  incurred.  Somewhere  the  system 
must  account  for  the  effort  (which  can  affect  overhead).  A  similar  cost  myth 
for  Government  data  managers  is  requesting  items  via  the  Data  Accession  List 
to  avoid  paying  for  information  which  might  be  the  case  if  the  information 
were  acquired  through  a  data  itsn  listing  on  the  Contract  Data  Requirements 
List. 

(5)  Yardstick  data  costs  with  measures  other  than  dollars.  For  instance, 
one  can  yardstick  time,  either  labor  time  or  machine  time.  Rates  may  vary  and 
accounting  systsns  may  place  effort  in  direct  or  indirect  categories,  but  a 
time  yardstick  allows  an  estimate  of  the  actual  amount  of  effort  and  resources 
involved  no  matter  what  the  accounting  system. 

(6)  Be  able  to  translate  between  the  various  systems  of  dollarizing  used 
in  industry  and  Government.  The  Government  requires  that  costs  be  presented 
in  a  certain  manner  and  many  contractors  use  different  estimating/accounting 


^Feeley,  The  Vital  Link,  p.  7-5. 
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procedures.  Government  estimating  (for  cost-type  contracts)  usually  is  based 
upon  a  treeing  of  costs  (labor,  material,  overhead,  general  S  administrative, 
CAS,  etc.)  and  profit/fee.  It's  a  very  common  practice  for  private  industry 
to  use  markup  pricing.  The  estimating  system  must  be  capable  of  converting 
from  one  format  to  the  other.  Ordinarily,  the  scope  of  work  remains  the  same, 
but  the  formats  change  depending  upon  user  requirements. 

(7)  Remember  that  you  as  a  contractor  data  manager  estimate  the  costs 
upon  which  future  actions  are  based.  Difficulties  can  be  eased  by  a  well 
documented  estimate  that  fully  addresses  user  requirements.  Your  estimate 
must  be  as  accurate  as  possible  to  help  make  a  winning  proposal  package. 

(8)  Use  line  item  costing  when  developing  your  estimate.  Even  though  the 
present  system  may  subsequently  induce  distortions  and  inconsistencies,  you 
have  established  a  budgeting  benchmark  for  future  use.  Contractors  are  re¬ 
quired  by  Government  to  price  data  items  one  by  one,  ostensibly  for  cost  visi¬ 
bility.  Often,  the  data  item  prices  subsequently  are  rolled  up  into  a  summed 
number  for  "data”  which  is  shown  as  a  contract  line  item  (CLIN).  In  fact, 

OAR  3-81 4(d)  requires  that  the  tag  end  of  the  Contract  Data  Requirements  List 
(OoD  Form  DO  1423),  where  individual  data  item  prices  are  shown,  not  appear  in 
contracts.  Roll-up  pricing  can  obscure  data  costs.  Perhaps  the  popularity 

of  roll-up  pricing  indicates  the  futility  which  exists  in  making  any  sense  out 
of  current  data  pricing  practices.  Furthermore,  the  Government  benefits  frcm 
CLIN  pricing  because  the  contractor  must  wait  until  all  data  items  are  com¬ 
pleted  before  the  CLIN  can  be  billed  (usually  at  the  end  of  the  contract). 

This  is  a  good  deal  from  the  Government’s  view  because  the  contractor  must 
work  on  his  own  nickel  before  getting  any  return,  especially  if  the  data  is 
not  subject  to  progress  payments.  Another  "gotcha"  occurs  even  with  line  itan 
pricing.  The  Government  routinely  imposes  the  Data  Withhold  clause, 

OAR  7-104.9 (h),  that  reserves  10  percent  of  the  total  contract  price  until  all 
data  itans  are  satisfactorily  completed  which  means  that  funds  equivalent  to 
most  (or  all)  of  the  data  effort  are  not  released  until  contract  end. 
Accordingly,  contractors  attempt  to  reduce  or  eliminate  this  clause  during 
negotiations. 

(9)  Find  a  better  way  of  billing  data  itans.  Progress  payments  often  are 
requested  and  used,  but  they  may  not  include  total  payments  for  data  items. 

The  submittal  of  data  itans  on  a  Letter  of  Transmittal  (LT)  with  a  summary  DoD 
Form  00  250  (Material  Inspection  and  Receiving  Report)  at  the  completion  of 
the  CLIN  is  another  method  of  billing  which  is  most  cost-effective  in  today’s 
system.  But,  no  payment  is  received  until  CLIN  completion.  Submitting  indi¬ 
vidually  priced  itans  with  the  DO  250  gets  payment,  but  often  the  cost  of 
processing  the  0D  250  is  greater  than  the  cost  of  the  data  item  being  shipped. 
If  the  user  is  willing  to  accept  billing  by  commercial  invoice,  then  the  use 
of  the  DD  250  can  be  lessened. 

(10)  Check  fur  cost  consistency.  If  user  requirements  are  accurately 
defined  and  understood,  different  estimators  will  arrive  at  similar  efforts. 
The  writer  has  participated  in  various  cost-estimating  exercises  that  have 
indicated  that  different  data  estimators  arrive  at  similar  figures  given  the 
same  requirements.  What  happens  is  that  these  initial  estimates  subsequently 
become  distorted  and  changed  as  they  go  through  the  review,  pricing,  and  nego¬ 
tiating  process.  Various  sources,  both  in  Government  and  industry,  show  simi- 
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lar  (although  perhaps  not  real)  effort  amounts  to  prepare  a  page  of  a  certain 
kind.  We  can  ballpark  the  costs  of  preparing  and  disseminating  a  unit  of 
information.  Consistency  in  DoD  price  grouping  (I,  II,  III,  or  IV)  is 
necessary. 

□nee  the  cost  of  generation  is  included,  the  information  cost  triad  is 
known.  Even  among  different  bidders,  true  costs  for  a  unit  of  information 
probably  are  similar.  Separately  revealed  information  costs  differ  and 
result  in  inconsistencies. 

The  basic  problem  of  cost  consistency  involves  how  much  of  the 
information  iceberg  is  seen,  not  the  size  of  the  iceberg. 

If  our  information  costing  systems  can  be  adjusted  to  consider  the  cost 
triad  associated  with  creation,  preparation,  and  dissemination,  we  will  have 
succeeded  in  reducing  inconsistencies. 

INFORMATION  is  our  most  valuable  resource.  The  true  cost  of  INFORMATION 
should  be  known.  Both  Government  and  industry  spend  a  great  deal  on  crusades 
to  reduce  the  cost  of  "paper”.  Unfortunately,  what  has  merged  is  a  system 
(involving  both  Government  and  industry)  that  clouds  rather  than  recognizes 
(or  reduces)  costs. 

The  key  to  consistency  is  to  recognize  that  the  basic  cost  of  information 
does  not  change  a  great  deal;  the  only  thing  that  changes,  under  present 
practices,  is  how  much  of  the  cast  is  separately  revealed.  Information  (data) 
is  a  product.  It  takes  many  forms.  The  data  effort  represents  a  large  (some 
say  30  percent  or  more)  part  of  program  costs.  Because  of  growth  of  software, 
the  data  percentage  is  increasing.  Information  is  composed  of  the  triad  of 
creation,  preparation,  and  dissemination.  To  reduce  the  inconsistencies,  we 
must  develop  a  costing  system  to  address  all  three  facets  of  the  information 
triad.  Next,  both  contractors  and  procuring  activities  must  similarly 
visualize  the  information  triad.  Only  then  can  we  realistically  examine  the 
issue  of  data  cost  effectiveness  and  achieve  cost  consistency. 


Supplement-8 


A  PEEK  AT  REASONS  FOR  INCONSISTENT  DATA  COSTS 

by 

Dr.  Ray  Calhoun 


presented  to 


The  26th  Annual  Meeting  of  the  Technical  Documentation  Division 

AMERICAN  OEFENSE  PREPAREDNESS  ASSOCIATION 


San  Antonio,  Texas 


May  1984 


/ 


Information^ 
/  * 


"DISSEMINATION- 


WHAT’S  THE  PROBLEM? 


"THE  CHIEF  PROBLEM  WITH  DATA  PRICING  TODAY  IS  THE  LACK  OF  INTEREST  AND 
KNOWLEDGE  OF  DATA  ON  THE  PART  OF  MOST  GOVERNMENT  CONTRACTING  OFFICERS." 

Cftirtn  R.  F—hy 


PAPER  IS  VIEWED  AS  A  PROGRAM  MANAGER'S  NEMESIS;  A  PROBLEM  AT  WORST, 

A  NUISANCE  AT  BEST 

DATA  -  WE  APPEAR  TO: 

OVERPRICE  IT 
UNDERPRICE  IT 
GIVE  IT  AWAY 
IGNORE  IT 

ROLL  IT  UP  AS  "NOT  SEPARATELY  PRICED"  OR  "PART  OF  EQUIPMENT"  TO  HIDE  IT 
TRY  TO  FORGET  ABOUT  IT 
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ALL  OF  US  ARE  A  PART  OF  THE  ACT 

BOTH  GOVERNMENT  AND  INOUSTRY  REPRESENTATIVES  COMPLAIN  ABOUT 
INCONSISTENCIES  IN  DATA/DOCUMENTATfON  COSTS 

BOTH  SHARE  IN  A  SYSTEM  WHICH  POSTERS  INCONSISTENCIES 

THE  SAME  REQUIREMENTS  CAN  RESULT  IN  BID  VARIATIONS  OF  TWENTY-TO-ONE 
AMONG  OFFERERS 

SOFTWARE  DATA  COSTS  OFFER  SIMILAR  FRUSTRATIONS 
SOME  SAY  WE  HAVE  BEEN  SWAMPED  BY  PAPER  COSTS 
“PAPER  HAS  A  TENDENCY  TO  BREED  AND  MULTIPLY."  c  Nortkcoti  RirkmiM 


IMPACT  OF  DATA 

30%  OF  SYSTEM  ACQUISITION  COST 
60%  OF  SPARES  COST 

90%  OF  RESEARCH  ANO  DEVELOPMENT  CONTRACTS  Ch.r*.  a  fm* 


WHY  DATA  COSTS  VARY  (ACCORDING  TO  DoD) 

DIFFERENCES  IN  BUSINESS  PRACTICES  IN  COMPETITIVE  SITUATIONS 
DIFFERENCES  IN  ACCOUNTING  SYSTEMS  AMONG  OFFERERS 
USE  OF  FACTORS  OR  RATES  ON  SOME  PORTION  OF  THE  DATA 
APPLICATION  OF  COMMON  EFFORT  TO  TWO  OR  MORE  DATA  ITEMS 
DIFFERENCES  IN  DATA  PREPARATION  METHODS  AMONG  OFFERERS 

Clauu  BAR  3  114(b) 
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INTERPRETATION  OF  WHERE  TO  DIVIDE  PREPARATION  TASKS  FROM 
PRODUCTION  TASKS  VARIES 


CONTRACTOR  DIVISION  GOVERNMENT  DIVISION 
OF  EFFORT  OF  EFFORT 


COST  TRIAD 


CREATION  TASKS 

[rESEARCH  &  ENGINEERING 
TO  DEVELOP  INPUT  INFO., 
PRELIM.  DRAFT 


CREATION  TASKS 

RESEARCH  &  ENGINEERING 
TO  DEVELOP  INPUT  INFO., 
PRELIM.  DRAFT 


CREATE 


PRODUCTION  TASKS 


EDIT  DRAFT 
jLLUSTRATE 

KEYBOARD,  REVIEW,  OA, 
FINAL  PRINTOUT 


EOIT  DRAFT 
ILLUSTRATE 

KEYBOARD,  REVIEW,  OA, 
FINAL  PRINTOUT 


PREPARE 


PRODUCTION  TASKS 


DISSEMINATE 


PRINTING 

DISTRIBUTION 


PRINTING 

DISTRIBUTION 


EMPIRICAL  REASONS  FOR  INCONSISTENT  DATA  COSTS 


DISLIKE  FOR  PAPER  STEMMING  FROM  UNDESIRABLE  CONNOTATION  GIVEN  BY 
OUR  SOCIETY 

POLICIES  -  OFFICIAL  AND  UNOFFICIAL 

BUDGET  AND/OR  ORGANIZATIONAL  PRESSURES 

DESIGNERS  THAT  DO  NOT  WISH  TO  BE  BOTHERED  BY  PAPER 

UNABLE  OR  UNWILLING  TO  OISCRETELY  DEFINE  DATA  IN  A  WAY  THAT  CAN  BE  COSTED 
OR  UNABLE  TO  00  ANYTHING  WITH  THE  UNFORTUNATE  (ALBEIT  WELL  INTENTIONED) 
DEFINITION  OF  DATA 

EDUCATIONAL  SYSTEM  THAT  TOO  OFTEN  FOREGOES  COMMUNICATIONS  SKILL  TRAINING 
AND  THUS  PRODUCES  INDIVIDUALS  THAT  ARE  ILL  PREPARED  TO  DEAL  WITH 
DOCUMENTATION  ASPECTS  OF  REAL-WORLD  PROGRAMS 

NEGOTIATING  TACTIC  WHERE  OBJECTIVE  IS  TO  INDUCE  DISCUSSION  OVER  DATA  ITEMS 
THEREBY  LESSENING  ATTENTION  TO  OTHER  ITEMS 

CONTRACTOR  MARKETING  TACTIC  WHERE  DATA  IS  OFFERED  AS  A  "LAGNIAPPE" 

WIDELY  VARYING  INTERPRETATIONS  OF  THE  FOUR  OATA  PRICE  GROUPS 
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INFORMATION  COST  TRIAD 


1.  CREATION 


COST  OF  CREATING,  GENERATING,  INVENTING,  AND/OR  ACQUIRING 
INFORMATION 


2.  PREPARATION 


COST  OF  PREPARING  THE  OATA  ITEM.  SUCH  AS  DRAFT  GENERATION, 
EDITING,  KEYBOARDING,  ILLUSTRATING,  PROOFREADING,  ETC. 

3.  DISSEMINATION 


COST  OF  REPRODUCING,  DISTRIBUTING.  MAINTAINING,  AND  STORING 
INFORMATION 


DATA  -  HOW  MUCH  OF  THE  INFORMATION  ICEBERG  SHOWS? 

BASIC  CREATION,  PREPARATION,  AND  DISSEMINATION  TASKS  APPLY  TO  ALL 
INFORMATION 

BASIC  INFORMATION  EFFORT  DOES  NOT  CHANGE  MUCH  -  THE  TRIAD  STILL  APPLIES 
INCONSISTENCIES  OCCUR  BECAUSE  OF  HOW  MUCH  OF  THE  TRIAD  IS  SHOWN  WHERE 
THE  BOTTOM  LINE  MUST  STILL  INCLUDE  THE  DATA 


REAL  COST  OF  OATA 
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PRICE  GROUPS  FOSTER  INCONSISTENCY 


GROUP  I  INCLUDES  ALL  THREE  PORTIONS  OF  COST  TRIAD 

GROUP  II  INCLUDES  PREPARATION  AND  DISSEMINATION  COSTS 

GROUP  III  INCLUDES  DISSEMINATION  COSTS  ONLY 

GROUP  IV  NO  CHARGE  DATA 

OATA  PRICE  GROUPS  ARE  SUBJECT  TO  WIDE  INTERPRETATION 

HOWEVER,  IN  ALL  INSTANCES  THE  BASIC  COST  OF  INFORMATION  HAS  NOT  CHANGED; 
IT  STILL  MUST  BE  CREATED,  PREPARED,  AND  DISSEMINATED  WHETHER  GROUP  I  OR  IV. 


WHAT  ARE  WE  REALLY  BUYING? 
INFORMATION 


INFORMATION  IS  WHAT  IS  PROCURED.  NOT  “PAPER" 

ANY  INFORMATION  IN  ANY  MEDIA  BECOMES  THE  PRIMARY  CONCEPT 

WE  MUST  CONCENTRATE  ON  THE  COST  OF  INFORMATION  CONTAINEO  ON  THE  PAGE 
NOT  THE  COST  OF  THE  PAGE 

INFORMATION  REMAINS  VITAL  -  PAGES  MAY  BECOME  OBSOLETE  AS  CARRIERS 
OF  INFORMATION 
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FACTORS  FOSTERING  CONSISTENCY 


CONSISTENCY  BEGINS  WITH  A  GOOD  PROCUREMENT  PACKAGE 

BELIEVE  YOUR  ESTIMATE 

STRIVE  FOR  INTERNAL  CONSISTENCY 

AVOID  THE  PITFALL  OF  THE  •‘FREE"  TYPIST  OR  “FREE"  ANYTHING 

YARDSTICK  DATA  COSTS  WITH  MEASURES  OTHER  THAN  DOLLARS  (SUCH  AS  TIME, 
EITHER  LABOR  OR  MACHINE) 

BE  ABLE  TO  TRANSLATE  BETWEEN  THE  VARIOUS  SYSTEMS  OF  DOLLARIZING  USED  IN 
INDUSTRY  AND  GOVERNMENT 

DOCUMENT  YOUR  ESTIMATE 

USE  LINE  ITEM  COSTING  WHEN  DEVELOPING  YOUR  ESTIMATE 

CHECK  FOR  COST  CONSISTENCY  AND  INTERPRETATION  OF  DATA  PRICE  GROUPS 

CONSIOER  ALL  THREE  FACETS  OF  THE  INFORMATION  COST  TRIAD 


KEYS  TO  CONSISTENCY 


RECOGNIZE  THAT  INFORMATION  IS  A  MOST  VALUABLE  RESOURCE  AND  ITS  TRUE 
COST  SHOULD  BE  KNOWN 

THE  BASIC  PROBLEM  OF  COST  CONSISTENCY  INVOLVES  HOW  MUCH  OF  THE 
INFORMATION  ICEBERG  IS  SEEN,  NOT  THE  SIZE  OF  THE  ICEBERG 

EVEN  AMONG  DIFFERENT  BIDDERS,  TRUE  COSTS  FOR  A  UNIT  OF  INFORMATION  ARE 
PROBABLY  SIMILAR 

BOTH  CONTRACTORS  AND  PROCURING  ACTIVITIES  MUST  SIMILARLY  VISUALIZE 
INFORMATION  COSTS 

BY  CONSIDERING  ALL  THREE  FACETS  OF  THE  INFORMATION  COST  TRIAD  (CREATION, 
PREPARATION,  AND  DISSEMINATION)  COST  CONSISTENCY  CAN  BE  ACHIEVED 

ONCE  CONSISTENCY  IS  ACHIEVED,  DATA  COST  EFFECTIVENESS  CAN  BE  EXAMINED 
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STATUS  OF  NATIONAL  DRAFTING  PRACTICES 
(new/recently  revised) 


American  Society  of  Mechanical  Engineers  (ASME) 

Y14.5  Dimensioning  and  Tolerancing  (Mr.  Nicovich)  -  Revised  1982. 

The  Subcommittee  has  resumed  work  on  resolving  the  deferred 
comments  and  preparing  the  next  revision  (scheduled  for 
1987)  . 


Y14.8  Casting  and  Forgings  (Mr.  Pickard)  -  Revision  still  in  work. 
Plan  to  combine  casting  and  forging  (latter  was  formerly 
Y14.9) 

Y14.13  Springs  -  New  chairman  needed. 

Y14.15  Electrical  and  Electronic  Diagrams  (Mr.  Muller)  -  IEEE 
has  assumed  responsibility  for  this  standard;  a  new 
number  will  be  assigned  at  the  next  revision.  Only 
Logic  Circuit  Diagram  Preparation  is  currently  in  work. 

Y14.18  Drawings  for  Optical  Parts  (Mr.  Beavers)  -  Public  Review 
comments  on  proposed  new  standard  currently  being 
addressed  by  subcommittee.  No  DoD  Acceptance  Notice  planned 

Y14.24  Types  and  Application  of  Engineering  Drawings  (Mrs.  Burns)  - 
Draft  of  proposed  new  standard  transmitted  to  ASME  for 
Y14  Standards  Committee,  DoD,  and  ANSI  Public  Reviews. 

Y14.26  Computer  Aided  Preparation  of  Product  Definition  Data 
(Mr.  Jones)  -  Standard  issued  1981  is  obsolete  since 
it  documents  only  Version  1  of  IGES.  Version  2  has  been 
completed  and  Version  3  is  eminent. 

Y14.34  Parts  Lists,  Data  Lists  and  Index  Lists  (Mr.  Dubocq)  - 
New  standard  issued  1982.  No  DoD  Acceptance  Notice. 

Y14.35  Drawing  Revisions  -  Public  Review  comments  on  the  proposed 
new  standard  will  be  addressed  when  a  new  chairman  has 
been  established  (one  has  been  proposed). 


Institute  of  Electrical  and  Electronic  Engineers  (IEEE) 

ANSI/IEEE  STD  91-1982,  Logic  Symbols  (invoked  by  DOD-STD-lOO, 
Notice  3)  -  Not  yet  published.  Copies  of  the  draft  approved  by 
ANSI/BSR  and  sent  for  typesetting  are  available  from  Conrad  Muller 
IEEE  (212/705-7960).  (The  Texas  Instruments  Data  Handbook  for 
Microcircuits  contains  a  concise  explanation  of  this  symbology 
which  is  used  in  their  handbook. ) 

IEEE  STD  991,  Logic  Circuit  Diagram  Preparation  -  Public  Review 
comments  on  proposed  new  standard  are  being  addressed  by  the  Coor¬ 
dinating  Committee. 
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ENGINEERING  DRAWINGS 


Attendees:  45  Industry 

18  Government 


A.  SECTION  ACTIVITY  REPORT  (L.  Burns) 

1.  Joseph  R.  Meitz,  Chairman  of  the  Engineering  Drawing  Require¬ 
ments  Section  (EDRS)  for  many  years,  has  retired  as  of  April  1984. 
He  is  in  good  health  following  last  years  cardiac  surgery.  Mr. 
Meitz  will  be  missed. 

Lorna  Burns  of  Hughes  Aircraft  Company  has  been  appointed  by  the 
TDD  Executive  Board  as  the  new  chairman.  She  welcomes  your  calls 
and  expects  that  the  drawing  section  will  continue  to  serve  both 
Industry  and  Government  as  it  has  in  the  past. 

2.  In  recent  months,  the  Section  has  reviewed  and  commented  on 
the  following  draft  proposals  for  new,  revised,  or  reaffirmed  ANSI 
standards.  Letter  Ballots  have  been  submitted  to  the  preparing 
organizations  ( ASME/IEEE )  on  behalf  of  ADPA  as  follows: 

ANSI/ASME  Y14.4,  Pictorial  Drawings  -  Approved  with 
comments  (4  pages) 

ASME  Y14.18,  Optical  Drawings  -  Approved  with  comments 
(14  pages) 

IEEE-STD-991,  Preparation  of  Logic  Circuit  Diagrams  - 
Approved  with  comments  (20  pages) 

NOTE:  As  a  standards  coordinating/approving 
organization  only  (ANSI  does  not  develop  any 
standards),  ANSI  no  longer  assigns  unique  ANSI 
numbers.  Rather  "ANSI/"  is  added  as  a  prefix 
to  the  preparing  organizations  identifier 
when  the  document  is  approved  as  a  national 
standard  by  the  ANSI  Board  of  Standards 
Review. 

Review  of  draft  proposals  will  be  an  ongoing  activity  within 
EDRS.  Those  who  wish  to  participate  in  the  review  of  such  pro¬ 
posals  were  invited  to  join  an  active  Review  Group  within  the 
Section.  The  need  for  active,  timely  participation  was  emphasized. 
It  is  essential  that  comments  are  received  by  the  specified  due 
dates  to  permit  consolidation  in  a  timely  manner.  Late  comments 
may  be  ignored  by  the  preparing  organization. 


3.  At  the  1983  Annual  Meeting,  formation  of  an  Ad  Hoc  Committee 
was  proposed  to  investigate  the  impact  of  automation  upon  the 
drawing  system  and  to  identify  the  changes  to  existing  specifications 
and  standards  needed  to  take  full  advantage  of  emerging  technologies. 
This  Ad  Hoc  Committee  was  officially  established  in  March  1984. 

Larry  A.  Ciskowski  of  Boeing  has  volunteered  to  serve  as  chairman. 


B.  AD  HOC  COMMITTEE  REPORT  ON  THE  EFFECT  OF  AUTOMATION  ON 
ENGINEERING  DRAWING  SYSTEMS  ( L. A .  Ciskowski) 

Mr.  Ciskowski  reassured  attendees  that  there  are  no  plans  to 
disrupt  the  existing  manual  drawing  systems;  the  manual  drawing 
systems  must  be  maintained  for  the  foreseeable  future. 

To  fully  utilize  automation,  however,  some  significant  changes 
will  be  required  in  DOD-D-1000,  DOD-STD-lOO,  and  related  industry 
standards.  Typical  changes  include: 

•  Expanding  the  definition  of  drawing  originals  to  include 
electronic  data  base  forms. 

•  Making  approval  requirements  compatible  with  automated 
methods . 

•  Revising  drawing  formats  to  be  compatible  with  automated 
systems . 

•  Discarding  obsolete  originals  when  the  original  exists  in 
electronic  data  base  form. 

The  need  for  Industry  to  adopt  and  implement  a  standard  neutral 
data  base  format,  such  as  IGES,  is  recognized;  not  only  at  this 
workshop,  but  by  several  of  the  1984  speakers  and  nationally. 


The  3-D  interactive  graphics  modeling  systems  may  require  a  change 
to  conventional  2-D  drawing  presentation  techniques.  The  3-D 
model  may  provide  a  configuration  definition  such  that  drawings 
as  we  know  them  today  may  not  be  required. 


The  committee  will  attempt  to  prepare  a  "white  paper"  in  these 
areas.  Anyone  wanting  to  participate  in  this  task  should  contact 
either  Mr.  Ciskowski  or  the  Section  Chairman. 


Curtis  Bauer  of  Aberden  Proving  Ground  recommended  that  awareness 
of  data  set  approval,  data  revision,  acceptable  electronics  media 
configuration,  and  what  constitutes  master  configuration,  be  ever 
in  the  contractors'  consciousness. 


C.  QUESTIONS  AND  ANSWERS 

1.  Two  controversial  questions  were  asked  that  suggest  that  a 
need  exists  to  rethink,  very  carefully,  what  information  is 
specified  on  drawings.  This  is  particularly  critical  in  view 
of  the  Congressional  interest  in  competitive  reprocurement  and 
spare  parts  cost-reduction.  These  questions  are: 

IQ  -  Should  we  minimize  the  use  of  company  specifications 
and  standards  and  maximize  the  use  of  military  and  industry 
specifications  and  standards? 

1A  -  Of  course. 

This  may  seem  like  a  strange  question,  particularly  considering 
that  it  was  submitted  by  a  knowledgeable  Air  Force  representative 
who  is  well  aware  of  the  order  of  precedence  for  selecting 
specifications  and  standards  required  by  MIL-STD-143.  This 
individual  was  making  a  point. 

In  practice,  there  is  a  wide-spread  proliferation  of  unique 
company  standards,  even  though  the  DOD  Index  of  Specifications 
and  Standards  already  lists  equivalent  specifications  or 
standards.  Often  these  unique  standards  are  the  result  of 
a  company  (or  even  a  military  activity)  establishing  a  level 
of  detail  (how-to  instructions)  beyond  that  necessary  to  ensure 
fit,  form,  and  functional  interchangeability  of  the  product. 

There  is  a  fine  line  between  specifying  complete  requirements 
and  over-specification  which  produces  unrecognizable  versions 
of  standard  requirements. 


2Q  -  What  part  number  control  applies  to  a  military  specifi¬ 
cation  part  purchased  with  leads  formed  and  tinned? 

2A  -  Many  at  the  workshop  were  quick  to  answer,  "that's 
an  altered  item."  But  is  it  really? 

MIL-STD-275  calls  for  lead  forming  requirements  to  be  specified 
on  the  assembly  drawing.  In  most  cases,  the  advanced  forming 
and  tinning  of  leads  is  merely  a  convenience  for  manufacturing. 
Virtually  any  competent,  trained  person  could  install  the  MIL-spec 
part  in  the  assembly — especially  under  wartime  conditions. 

We  should  not  complicate  the  Supply  system  by  introducing: 

(1)  unnecessary  nonstandard  part  identification,  and  (2)  the 
attendant  delays  which  occur  until  someone  finally  figures 
out  that  it  is  really  a  standard  part. 

RECOMMENDATION:  Devote  a  workshop  session  at  the 
1985  Annual  Meeting  to  exploring  the  impact  of 
drawings  on  Supply. 


2.  The  following  additional  questions  were  presented  by  the 
workshop  attendees  for  response  by  the  panel: 

IQ  -  Does  the  EDRS  plan  to  publish  synopses  of  changes  between 
old  and  new  issues  of  standards? 

1A  -  The  ANSI  Y14  series  standards  contain  a  description  of  the 
changes  in  the  Foreword  of  the  standard  or  in  an  historical 
appendix  when  the  committee  feels  that  such  information  is  of 
value;  therefore  such  synopses  will  be  developed  only  when 
there  is  some  unusual  complexity  or  impact.  (We,  of  course, 
need  volunteers  to  do  the  work.) 


2Q  -  Are  there  plans  to  allow  part  numbers  in  excess  of  15  characters 

2A  -  No  -  It  is  explicitly  controlled/limited  to  15  characters. 

NOTE:  Arnold  Batina  of  Ball  Aerospace,  Boulder,  CO  indicated 
he  had  heard  here  was  a  letter  published  by  DMSSO  which 
provided  for  special  applications . 

ACTION  ITEM:  L.  Burns  subsequently  contacted  DMSSO 
regarding  the  question.  We  have  been  assured  that 
no  such  change  has  been  approved;  however  there  is 
a  request  from  the  Air  Force. 

3Q  -  When  re identi f ying  military  specification  numbers  greater 
than  15  characters  (e.g.  descriptive  identifiers,  type,  class 
grade,  etc)  with  a  company  control  drawing,  is  a  nonstandard 
part  approval  required? 

3A  -  No — but  to  maximize  useability  of  the  engineering  documen¬ 
tation,  the  identification  control  number  should  be  treated 
as  a  reference  number  and  the  complete  MIL-spec  identification 
included  in  the  Description  field  of  the  Parts  List  or  in  the 
Material  block  of  the  drawing. 

4Q  -  What  is  the  consensus  of  the  group  in  applying  the  new 
ANSI  Y14. 5M-1982  dimensioning  and  tolerancing  symbols  in  lieu 
of  words? 

4A  -  The  intent  of  the  symbols  is  to  establish  a  universal  (ISO) 
language  for  dimensioning  and  tolerancing.  This  minimizes  the 
amount  of  translation  of  English  vocabulary  necessary  when 
drawings  are  used  Internationally.  Very  few  of  those  present 
had  implemented  the  symbols  yet. 

5Q  -  When  an  ANSI  specification  is  referenced  in  notes  on  a  drawing, 
must  the  date  of  the  specification  be  included? 

5 A  -  ANSI  specifications  include  the  date  as  an  integral  part  of 
the  specification  number.  Yes,  the  date  must  be  included  (e.g.; 

ANSI  Y14. 5M-1982) . 


6Q  -  Relative  to  MIL-D-5480,  Class  2  (reproducible),  is  the  word 
"copy"  to  be  interpreted  as  "reproducible"  in  defining  a  fourth 
generation  print? 

6 A  -  Yes. 


7Q  -  Relative  to  6Q,  does  the  fourth  generation  have  to  produce  a 
legible  copy? 

7 A  -  Yes,  however  the  legibility  of  this  fifth  generation  copy 
is  a  by-product  of  the  fourth  generation  meeting  the  legibility 
requirements  of  MIL-D-5480. 


8Q  -  Is  MIL-D-5480  being  revised?  Where  is  "drawing  copy"  vs 
"non-drawing  copy"  defined? 

ACTION  ITEM:  L.  Burns  will  contact  the  Preparin' 
Activity  for  further  clarification. 


9Q  -  When  are  we  going  to  have  an  improved  definition  for  specifica¬ 
tion  control  drawings? 

9A  -  The  Preparing  Activity  for  DOD-STD-IOQ  was  given  a  proposed 
"Draft"  to  reidentify  and  clarify  specification  and  source  control 
drawings  (Tech  Report  25  June  1980)  in  which  one  recommendation 
is  to  change  "Specification  Control"  to  "Vendor  Item"  Drawing. 

There  has  been  no  formal  response  to  this. 


10Q  -  Who  is/isn't  labeling  CAD  generated  drawings?  and  how? 

10A  -  Attendees  using  CAD  drawings  fell  into  three  groups: 

a.  Approximately  half  were  not  labeling  CAD  drawings. 

b.  Approximately  25  percent  label  drawings  with  a  tape 
(program)  file  number  in  the  border  of  the  drawing. 

c.  The  remainder  label  their  drawings  above  the  title  block 
with  a  notations  such  as  "COMPUTER  GENERATED  DRAWING" 
and  the  file  number. 

It  was  the  consensus  of  those  present  that  inclusion  of  the  data 
base  file  number  on  the  field  of  the  drawing  tends  to  imply  that 
the  file  is  a  part  of  the  data  package  and,  therefore,  potentially 
deliverable.  If  such  notation  is  needed  for  internal  purposes 
only,  it  should  be  placed  in  the  drawing  border. 


A 


11Q  -  When  a  drawing  defines  a  "blown"  PROM  or  EPROM,  is  the  drawing 
an  "Altered  Item"?  If  the  EPROM  is  erased  and  changed,  is  it  still 
considered  to  be  "Altered"? 

11A  -  A  blown  PROM  (or  EPROM  programmed  as  an  individual  part) 
is  an  altered  item  drawing.  If  an  EPROM  is  programmed  in  its 
using  assembly,  any  alteration  or  change  to  that  program  is 
a  change  to  the  using  assembly  part  number. 


12Q  -  What  is  the  meaning  of  the  signature  in  the  approval  block? 
Does  it  mean  the  drawing  meets  drafting  standards,  or  is  released, 
or  design  meets  customer  specification,  or  other? 

12A  -  There  is  no  government/industry  standard  that  establishes 
uniform  meaning.  Individual  company  procedures  generally 
define  the  criteria  for  such  signatures.  Typically,  such  signa¬ 
tures  indicate  that  to  the  best  of  the  signer's  knowledge  and 
responsibility,  the  drawing  adequately  and  accurately  describes 
the  item  such  that  it  can  be  used  for  the  intended  purpose. 


13Q  -  What  is  the  status  of  the  ANSI  casting  and  forging  drawing 
standard? 

13A  -  Draft  is  still  in  ASME  Y14.8/9  Subcommittee. 


14Q  -  What  Data  Item  Description  is  being  used  for  the  on-line 
engineering  documentation  being  used  for  Pershing  II  that 
Charles  J.  Borum  described  in  his  presentation  (see  his  paper 
in  these  proceedings)? 

14A  -  DI-E-1101C  supplemented  by  the  Statement  of  Work  which 

says  that  data  supplied  on-line  need  not  be  supplied  in  hardcopy 
form. 


15Q  -  Can  computer  programs  which  are  stored  and  released  on 
electronic  media  (e.g.,  magnetic  tape,  punched  tape,  floppy 
disk,  etc)  be  shipped  as  part  of  a  data  submittal  package  or 
do  hardcopy  "drawings"  have  be  be  made  for  these  computer 
programs? 

15A  -  This  depends  on  your  specific  contractual  requirements. 

Check  the  applicable  CDRL  and  the  Data  Item  Descriptions  refer¬ 
enced  therein. 


16Q  -  Do  drawings  have  to  be  signed  or  can  we  utilize  an  on¬ 
line  sign-off  method  where  each  signature  is  typed? 


16A  -  At  this  time,  this  is  a  gray  area.  A  variety  of  methods 
are  being  used  by  various  contractors  including: 

•  A  note  on  the  drawing  which  refers  to  internal 
release  records  for  approval  signatures. 

•  Use  of  a  light  pen  to  sign  on  the  "tube". 

•  Internal  procedures  that  establish  password  control 
and  identifying  symbology. 

Such  procedures  need  to  be  documented  and  provide  adequate 
control  to  ensure  the  integrity  of  the  documentation. 


NOTE:  When  drawings  are  redrawn,  prior  approval  signatures 
are  generally  printed;  not  re-signed.  The  approval  signatures 
for  the  redraw  are  contained  either  in  the  Revision  block 
of  the  drawing  or  in  the  change  authorization  document. 


D.  THANKS  to  the  Panel  members  and  Attendees  for  their  active 
participation. 


Edward  O.  Gonzalez  CRESC  Jerome  H.  Lieblich  Global  Engineering  Documents  (800)854-7179 

San  Antonio  Air  Logistics  Ctr  (512)925-7324  2825  S.  Hickory  Street 
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WORKSHOP  #3 


ILS/TECHNICAL  PUBLICATIONS 
MEETING  REPORT 

WORKSHOP  PARAMETERS  -  The  ILS/Technical  Publications  Workshop  was  conducted 
from  1315  to  1700  on  May  8,  1984  in  the  Terrace  Room  of  the  El  Tropicano  Hotel, 

San  Antonio,  Texas.  This  workshop  was  a  part  of  the  Twenty-Sixth  Annual  Meeting 
of  the  Technical  Documentation  Division,  American  Defense  Preparedness  Association. 

Workshop  #3  was  attended  by  36  participants  (8  government  and  28  industry 
representatives).  The  roster  identifies  each  participant  by  name  and  affiliation. 

OVERVIEW  -  The  Workshop  Chairman  convened  the  session  by  presenting  a  brief 
report  on  the  status  of  last  year's  action  items.  Two  areas  of  follow-up  action 
were  reported: 

The  first  area  involved  assistance  in  the  Technical  Manuals  Specifications 
and  Standards  (TMSS)  program.  The  Program  Plan  for  this  effort  was  first  approved 
in  January,  1980  and  revised  in  July,  1983.  This  plan  was  developed  and 
coordinated  with  the  DOD  Components  and  Industry  by  the  U.S.  Army  DARCOM  Material 
Readiness  Support  Activity,  Lexington,  KY,  the  Lead  Service  Activity.  The  tasks 
identified  in  the  plan  have  been  approved  by  the  Joint  Logistic  Commanders  (JLCs). 

It  was  noted  that  the  TMSS  Chairman,  Mr.  Art  Rulon  of  DARCOM,  was  to  present  a 
TMSS  status  report  during  Session  III  (May  9,  1984)  of  the  26th  Annual  Meeting 
(his  presentation  is  included  in  the  minutes  of  the  General  Membership  Meeting). 

A  copy  of  the  latest  (July  1983)  TMSS  Program  Plan  was  available  at  the  workshop 
session  for  reference.  There  is  no  publication  number  assigned  to  this  document, 
but  copies  (no  cost)  are  available  under  the  title  "Technical  Manuals  Specifications 
and  Standards  (TMSS)  Program  Plan"  dated  July,  1983  by  writing  to: 

Naval  Publications  and  Forms  Center 
5801  Tabor  Avenue 
Philadelphia,  PA  19120 

Attention:  Customer  Service  -  Code  1052 
(Telephone  (215)  697-2667) 

Further  action  on  TMSS  tasks  is  anticipated,  and  25  of  the  28  industry  participants 
indicated  a  desire  to  serve  when  TMSS  industry  coordination  is  requested. 


The  second  area  involved  follow-up  to  the  NAVSEA  Modular  Specification 
System  (M-SPECS)  that  is  now  identified  by  the  acronym  TMARS  (Technical 
Manual  Acquisition  Requirements  System).  A  TMARS  briefing  was  scheduled  for 
Session  III  (May  9,  1984)  of  the  26th  Annual  Meeting  but  was  cancelled  at  the 
11th  hour.  In  the  Workshop  #3  summary  report  to  the  general  membership  (Session  V) , 
comments  were  solicited  from  those  having  either  favorable  or  unfavorable  experience 
with  the  TMARS  approach.  It  was  requested  that  such  comments  be  sent  directly 
to: 

Naval  Sea  Data  Support  Activity  ( NSDSA) 

Naval  Ship  Weapon  Systems  Engineering  Station  (NSWSES) 

Port  Hueneme,  CA  93043 
Attention:  L.R.  Melton  -  Code  5730 
(Telephone  (805)  982-5093/4319) 

Following  the  action  item  coverage,  the  Workshop  Chairman  briefed  the  participants 
on  the  ILS/Technical  Publications  issues  that  surfaced  during  the  two  Executive 
Board  Meetings  (Sept. '83  Meeting  at  the  Boeing  Kent  Space  Center,  Kent,  WA  and 
Feb. '84  Meeting  at  the  Defense  Logistics  Agency  ( DLA ) ,  Cameron  Station,  Alexandria, 
VA).  Minutes  of  these  Executive  Board  Meetings  contain  the  details  of  these 
issues. 

After  the  introductory  report,  the  purpose  and  operating  procedures  for  the 
workshop  session  were  given.  "Question/Problem”  forms  were  made  available  to 
workshop  participants  and  as  a  result  of  this  solicitation,  five  workshop  issues 
were  identified  for  discussion.  To  prepare  for  the  discussion,  each  participant 
was  asked  to  identify  individual  background  information  such  as  name,  affiliation, 
position,  and  brief  sketch  of  applicable  experience.  The  Workshop  Chairman  then 
stressed  that  each  participant  should  contribute  as  an  individual  rather  than 
as  a  representative  of  the  affiliated  company  or  military  service.  Using  this 
approach,  the  workshop  objective  was  established  as  the  resolution  of  the 
"Question/Problem"  issues  that  would  best  serve  American  Defense  Preparedness. 


I 


WORKSHOP  ISSUE  1  -  STANDARD  FOR  DIGITAL  DELIVERABLES 


PROBLEM:  Many  companies  have  automated  their  technical  publications 

preparation  functions.  DOD  agencies  such  as  the  Air  Force 
with  ATOS  are  moving  into  automation  and  indicate  they  will 
require  a  digital  deliverable.  DOD  must  develop  a  standard 
or  specification  up  front  to  define  that  digital  deliverable. 
Without  that  spec  or  standard,  the  systems  developed  by 
contractors  may  become  obsolete  when  DOD  decides  to  develop 
this  spec  or  standard. 

DISCUSSION  HIGHLIGHTS:  Reference  was  made  to  the  Task  4  effort  of  the 

TMSS  Program  Plan  (July  1983).  The  title  of  this  task  is 
"Investigate  the  Development,  Implementation  and  Impact 
of  Electronic  (Digital)  Delivery  of  Technical  Information 
to  the  Service  Operators  and  Maintainers  as  a  Substitute  or 
Supplement  to  Hard  Copy  Technical  Manuals."  Under  the 
Task  4  scope,  system  examples  are  identified  by  the  acronyms 
ATOS,  PEAM, NTIPS ,  TICCIT,  NOMAD.  One  objective  of  Task  4 
is  to  assess  the  need  for  management  control  in  the  introduction 
of  the  technology  and  for  specifications  and  standards  for 
the  hardware  and  software  systems  involved.  This  segment 
of  the  discussion  stressed  the  awareness  and  attention  this 
problem  is  being  given  in  the  TMSS  effort. 

Another  segment  of  the  discussion  involved  current 
attempts  to  establish  a  standard  applicable  to  the  interchange 
of  information  among  remote  locations,  using  a  variety  of 
input  and  output  devices  and  processing  systems.  Reference 
was  made  to  Standard  101-1983  from  the  Graphics  Communications 
Association  adopted  by  the  Department  of  Defense  on  10  August 
1983.  This  standard  implements  the  Document  Markup 
Metalanguage  "GENCODE"  and  the  Standard  Generalized  Markup 
Language  (SGML).  Reference  was  made  to  the  Proceedings 
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of  the  24th  Annual  Meeting  of  the  Technical  Documentation 
Division  (San  Diego,  CA  on  24-27  May  1982).  Both  the 
presentation  by  Richard  C.  Sisman  on  "Generic  Text  Coding" 
and  the  Workshop  #3  ILS/Technical  Publications  Meeting  Report 
were  cited.  Those  wishing  to  obtain  a  copy  of  Standard 
101-1983  should  contact  the  following  for  price  and  ordering 
information : 

I 

Graphic  Communications  Association 
1730  North  Lynn  Street/Suite  604 
Arlington,  VA  22209 
(Telephone  (703)  841-8160) 

The  discussion  stressed  the  need  for  timely  release 
of  interface  specif ications  and/or  standards  to  define  digital 
deliverables  but  recognized  the  sizeable  coordination  effort 
required  to  accomplish  this.  Much  of  the  urgency  could  be 
relieved  if  the  standard  followed  the  Gencode  type  of  approach 
which  allows  for  a  variety  of  input  and  output  devices  and 
processing  systems. 

RESOLUTION:  Continue  to  keep  informed  of  progress  on  the  TMSS  Task  4 

mission.  Provide  assistance  as  requested  to  support  this 
effort.  Continue  to  monitor  developments  in  the  Gencode, 
optical  disc  and  video  disc  areas. 

WORKSHOP  ISSUE  2  -  TECHNICAL  DATA  COSTING 

QUESTION:  What  is  the  most  effective  way  to  accurately  assess  the  cost 

of  tech  data  (SPTD,  PPL,  Illustrations,  etc.)?  Since  one 
contractor  uses  engineers  to  complete  most  of  the  data  and 
another  uses  engineering  technicians,  etc. 

DISCUSSION  HIGHLIGHTS:  To  accurately  assess  the  cost  of  technical  data, 

the  evaluator  must  recognize  that  under  the  free  enterprise 
system,  industry  is  not  restricted  to  a  single  modus  operandi 
or  accounting  system.  This  makes  across  the  board  evaluations 
more  difficult  (if  not  meaningless)  but  does  encourage 
innovation  and  creativity  in  problem  solving.  Many  variables 


were  discussed  such  as  degree  of  automation,  use  of  indirect 
versus  direct  resources,  allocation  of  costs  to  common  use 
effort,  type  of  personnel  assigned.  Within  any  single 
organization,  the  accurate  assessment  is  made  because  the 
variables  are  fixed  for  that  organization.  For  meaningful 
evaluations,  the  backgrounds  and  approaches  of  the  different 
organizations  must  first  be  determined  before  attempting 
comparison.  Reference  was  made  to  a  recent  presentation 
made  by  Mr.  C.  Ayres  of  the  DARCOM  Material  Readiness  Support 
Activity  entitled  "Technical  Manual  Cost  and  Volume  Study" 
dated  July  1983. 

RESOLUTION:  Recognizing  that  comparison  of  apples  and  oranges  will  bear 

fruitless  results,  evaluators  must  first  identify  the 
variables,  determine  the  individual  approaches  taken,  and 
then  review  individual  histories  to  accurately  assess 
technical  data  costing. 

WORKSHOP  ISSUE  3  -  GUIDELINES  FOR  TECHNICAL  MANUALS 

PROBLEM:  we  had  trouble  finding  the  exact  guidelines  on: 

.  Specific  illustration  requirements  (when  to  phantom, 
call  out  all  parts,  etc.) 

.  Error  rates  for  Service  TM's,  Parts  TM's  DEP  VS.FDEP 

It  ended  up  that  we  received  written  "direction".  We  are 
concerned  however  that  the  "direction"  is  based  strictly 
on  local  interpretation  of  loosely  worded  standards. 

DISCUSSION  HIGHLIGHTS:  During  the  discussion  it  was  determined  that  this 
problem  was  submitted  by  a  participant  who  has  not  had 
much  past  dealings  with  DOD  technical  manual  requirements. 
Attention  to  contractual  requirements  was  stressed  as  well 
as  the  intent  of  loosely  worded  standards.  The  prime 
obligation  is  to  the  user  to  insure  good  communication  of 
operating  and  maintenance  techniques  that  will  reflect  the 
design  parameters.  Guidelines  that  are  too  narrow  in  scope 
restrict  your  flexibility  in  meeting  your  prime  objective. 


RESOLUTION: 


WORKSHOP  ISSUE 
QUESTION: 

DISCUSSION 


RESOLUTION 


WORKSHOP  ISSUE 
QUESTION: 

DISCUSSION 


Attempt  to  pattern  your  approach  to  the  user.  This  can 
best  be  accomplished  by  working  through  your  government 
counterDarts  since  they  have  the  same  prime  objective. 

The  s  ccess  of  your  approach  will  be  measured  during  the 
verification  procedure. 

:  -  DID  MODIFICATION 

Is  there  any  effort  being  taken  to  prevent  the  specifying 
activities,  when  writing  IFBs/RFPs,  from  modifying  DIDs 
indiscriminately,  causing  industry  to  continuously  rethink 
at  the  bid  stage? 

HIGHLIGHTS:  Reference  was  made  to  TMSS  Task  2  (Development  of 

DID  Tailoring  Procedures  and  Consolidation  of  existing 
DIDs)  and  Task  3  (Analyze  DODISS  and  non-DODISS  TMSS 
Documents  and  Related  DIDs  to  identify  Overlap  and  Duplication 
with  Potential  for  Consolidation  and/or  Cancellation).  These 
high  priority  TMSS  tasks  indicate  the  stress  that  DOD  is 
putting  on  reducing  and  managing  the  DIDs.  The  possibility 
of  acquiring  Technical  Manuals  as  contract  line  items  is 
also  being  considered  which  would  remove  them  from  the  CDRL 
and  DID  approach. 

The  problem  is  well  recognized  by  DOD  and  steps  are  underway 
to  improve  the  use  of  DIDs  as  a  management  acquisition  tool. 
Consolidation  is  the  objective  not  expansion  or  large  scale 
modif ication . 

-  TECHNICAL  INFORMATION  MANAGEMENT  SYSTEM 

Is  there  anyone  looking  at  a  Technical  Information  Management 
(TIMS-Army)  approach  -  a  systems  architecture/standard  for 
integration  of  CAPS/LSAR/CM/CAD-CAM? 

HIGHLIGHTS:  This  question  was  in  follow-up  to  a  TIMS  presentation 

given  by  Col.  Mark  Reese  at  a  recent  NSIA  ILS  meeting.  The 
management  system  was  presented  as  a  womb  to  tomb  concept 


Jim  Richardson  indicated  that  this  matter  was  tasked  to 
Defense  Information  Analysis  (DIA)  for  consideration. 

RESOLUTION:  Considering  the  inpact  of  such  a  system,  progress  on  the 

TIMS  approach  will  be  given  appropriate  follow-up. 

RECOGNITION:  Special  thanks  are  in  order  for  the  excellent  setting  provided  by 

the  El  Tropicano  Hotel. 

Also,  the  attendance  and  active  participation  of  Jim  Richardson  and  Burt  Newlin 
did  much  to  achieve  the  communication  level  that  was  realized.  Although  not 
established  as  a  formal  panel,  these  participants  formed  the  backbone  of  the 
workshop  session.  The  entire  session  was  devoted  to  issues  brought  up  by  the 
participants.  The  three  key  areas  of  concern  prepared  by  the  Workshop  Chairman 
were  not  addressed  due  to  lack  of  time.  These  issues  have  been  tabled  till  the 
27th  Annual  Meeting. 
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WORKSHOP  #3 

ILS/TECHNICAL  PUBLICATIONS 
ROSTER 


NAME 

Richard  E.  Knob 
John  Curtin 
Al  Ebeling 
John  P.  Campbell 
Alan  Johnson 
Burt  Newlin 
Earnest  W.  Deadwyler 
Warren  Knutson 
Richard  Robinson 
R.  G.  Sarkies 
Mario  Ramirez 
Susano  Mascorro 
Alfred  White 
Lamar  Williams 
Angelo  Christiano 
Ralph  P.  Brown 
David  A.  Patterson 
Garth  H.  Payne,  Jr. 
Carl  D.  Krebs 
Ray  Nichols 
Vernon  Bednard 
Linus  Glowienka 
Leon  Snodgrass 
Francis  R.  Sullivan 
Robert  B.  Quillen 
Clifford  G.  Wayne 
Ivan  L.  Bengtson 
Kenneth  L.  Dion 
Carles  A.  Miller 


AFFILIATION 
Sperry  Corporation 
Kollsman  Inst.  Co. 

ABA  Industries 
BMAC  Wichita 
BCS  Wichita 
DMSSO 

Texas  Instruments 
Pacific  Car  &  Foundry  Co. 

Pacific  Car  &  Foundry  Co. 

Boeing  Aerospace  Co. 

Hq.  AFALC/PTJ 
ASD/YZF  WPAFB,  OH. 

ARINC  Research  Inc.  San  Diego 
Newport  News  Shipbuilding 
ORI ,  Inc. 

XMCO  Inc. 

Chevrolet  Motor  Div. 

FMC,  Inc. 

AT&T/ Doc . Dev . Org . 

AT&T  Technologies  -  Fed.Sys.Div. 
TACOM,  Warren  MI. 

Ken  Cook  Co. 

EG&G  Washington  Analytical  Services 
Ford  Aerospace,  Colorado  Springs 
Honeywell  -  Clearwater,  FL 
Electronic  &  Support  Services,  Inc. 
National  Security  Agency  (NSA) 
General  Dynamics  Land  Systems 
Finkelstein  Associates,  Inc. 


NAME 


AFFILIATION 


Gene  Wright 
John  Scotton 
Richard  H.  Suskind 
Jack  Hamilton 
Emmett  Boyd 
Edward  McIntyre 
Jim  Richardson 


TPC  Logistics  Services  Inc. 

USA  CECOM  Pt.  Monmouth  (DME) 
Lockheed  (LAD) 

Raytheon  MSD/ILS 
Litton  Systems  Inc. 

National  Security  Agency  (NSA) 
DMSSO 


i 


I 


CHAIRMAN: 


PANEL 

MEMBERS: 


SUBJECTS: 


AGENDA 


Workshop  #4 

Configuration  Management 
Wednesday,  May  9,  1984  -  1315  Hours 


Mr.  Charles  J.  Embrey 
MITRE  Corporation  (W458) 
1820  Dolley  Madison  Blvd. 
McLean,  VA  22102 
TELEPHONE:  703-883-7420 


Ms.  Julie  Thomas 
TRW  (Wl/3530) 

7600  Col  shire  Dr. 

McLean,  VA 

TELEPHONE:  703-734-6240 

Mr.  John  Kick 
ASD/AWZ 

WPAFB,  Ohio  45432 
TELEPHONE:  513-255-2687 
A V  785-2687 

Mr.  James  Remiker 

General  Dynamics 

Convair  Division  (MZ23-6060) 

P.0.  Box  85357 

San  Diego,  California  92138 

TELEPHONE:  619-573-8588 

Mr.  Michael  Long 
E-Systems,  Mel  par 
7700  Arlington  Blvd. 

Falls  Church,  VA  22046 
TELEPHONE:  703-560-5000  X2885 

1.  HR  5064 

"Defense  Spare  Parts  Procurement  Reform  Act" 

Sponsor  -  Congressman  Nichols  (D),  Alabama 

2.  Professional  Certification  for  Configuration 
Management  Personnel 

3.  Questions/Discussions  Posed  by  the  Workshop  Attendees 
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4.  Development  of  an  Action  Item  List  for  Unanswered/ 
Unresolved  Items  to  be  Worked  On  During  the  Coming 
Year. 

WORKSHOP  PURPOSE: 

The  purpose  of  the  Configuration  Management  Workshop  was  to 
utilize  the  knowledge  gained  by  the  government  and  industry  partici¬ 
pants  who  work  with  and  apply  this  management  discipline  on  a  day-to- 
day  basis,  and  also  improve  communications  regarding  CM  matters 
between  all  of  the  attendees.  The  objective  of  the  workshop  was  to 
identify  and  resolve  problems  which  are  currently  being  experienced 
by  the  attendees,  through  questions  and  answers  posed  by  both  the 
panel  and  the  attendees.  Those  problems  which  required  specification 
changes  to  resolve,  or  were  otherwise  too  time-consuming  or  complex 
to  resolve  at  the  workshop,  were  recorded  as  action  items  and  will  be 
addressed  by  the  CM  committee  during  the  coming  year. 
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WORKSHOP  SUMMARY: 


Mr.  Charles  Embrey  opened  the  workshop  and  introduced  the  panel 
members.  The  workshop  attendees  were  provided  with  copies  of  the 
proposed  H.R.  5064,  Subject:  "Defense  Spare  Parts  Procurement  Reform 
Act,"  on  Tuesday,  May  8.  There  were  a  number  of  questions  concerning 
that  proposed  bill  which  were  previously  written  and  submitted  to  the 
Chairman.  Those  questions,  plus  comments  and  questions  from  the 
attendees  during  the  course  of  the  workshop  on  HR  5064,  the  certifi¬ 
cation  of  CM  personnel,  and  CM-related  topics,  formed  the  basis  of 
the  workshop's  activities. 

Mr.  James  Richardson,  Staff  Director,  Technical  Data  Division, 
Defense  Material  Specifications  and  Standards  Office,  addressed  the 
subject  of  HR  5064  on  Tuesday,  May  8,  which  provided  the  workshop 
attendees  with  a  general  overview  of  that  bill  and  85  similar  bills 
concerning  spare  parts  procurement  currently  in  process  within  Congres 

HR  5064: 

1.  General  comment  -  The  proposed  bill  was  too  lengthy  and  detailed 
to  discuss  in  its  entirety  during  the  course  of  one  workshop. 

2.  Specific  Questions/Comments: 

a.  Who  has  design  responsibility  for  spare  parts?  The  DAR 
Supplement  No.  6  of  Jun  83  defines  "Actual  Manufacturers," 
and  the  FAR  has  incorporated  Sup.  #6  in  total. 


It  was  noted  by  a  number  of  the  attendees  that  the  proposed 
bill  is  a  "shot  gun  approach"  to  resolving  the  spare  part 
procurement  problems,  and  the  subject  of  "multi-year  parts 
buy"  was  not  adequately  addressed  by  the  bill. 

The  workshop  attendees  were  in  general  agreement  that  the 
replenishment  of  spares  does  drive  the  cost  of  spares  up  when 
those  procurements  are  made  by  individual  FY.  Determination 
of  spares  requirements  should  be  made  for  program  out-years, 
in  the  early  stages  of  the  acquisition  process. 

It  was  also  noted  that  the  government  procurement  activities 
are  concerned  with  economical  spares  replenishment,  but  manu¬ 
facturers  currently  require  that  large  quantities  be  procured 
to  effect  a  cost  savings  per  unit  procured. 

The  workshop  attendees  discussed  the  following  specific  section 
of  the  proposed  bill  at  length. 

(1)  Pages  8  and  9 

"  Para  2386a.  Rights  in  technical  data  and  computer  software 
"(a)  A  contract  for  supplies  entered  into  by  the 
Department  of  Defense  which  provides  for  delivery  of  technical 
data  or  computer  software  to  the  United  States  shall  provide 
that  the  United  States  shall  have  unlimited  rights  in  -- 

"(4)  technical  data  necessary  to  enable  manufacture 
of  end-items,  components,  and  modifications,  or  to  enable  the 
performance  of  processes,  when  the  end- items,  components, 


modifications  or  processes  have  been,  or  are  being,  developed 
under  a  Government  contract  or  subcontract  in  which  experi¬ 
mental,  developmental,  or  research  work  is  or  was  specified 
as  an  element  of  contract  performance,  except  technical  data 
pertaining  to  items,  components,  processes,  or  computer 
software  developed  at  private  expense; 

(2)  Page  11 

"(2)  Each  contract  described  in  paragraph  (1)  shall  provide 
that  if— 

"(A)  the  contractor  asserts  that  the  United  States  is 
not  entitled  to  unlimited  rights  in  technical  data  relating 
to  an  item,  component,  or  process;  and 

"(B)  the  assertion  is  not  sustained  and  it  is  determined 
that  the  assertion  was  not  substantially  justified, 
the  contractor  shall  be  required  to  pay  to  the  United  States 
the  costs  to  the  United  States  of  contesting  the  assertion." 

f.  It  was  suggested  by  the  attendees  that  the  terms,  "Developed 
at  Private  Expense,  Manufacturing  Data,  and  Data  Management 
Subsystems"  be  further  defined  as  used  in  the  proposed  bill. 

g.  General  conclusions  reached  by  the  attendees  on  HR  5064  were: 
(1)  HR  5064  appears  to  be  redundant  of  existing  regulations, 
provides  no  apparent  additional  benefits  and  adds  significant 
costs  to  the  acquisition  system.  Such  suggestions  as  the 
"personnel  appraisal  system"  which  shall  be  established 
encourages  costly  "witch  hunts"  to  realize  some  unknown  reward. 
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(2)  Other  regulations  included  in  this  Bill  are  establishing 
requirements  contrary  to  currently  operating  procedures  and 
should  be  eliminated  or  fully  coordinated  prior  to  acceptance. 

(3)  It  is  suggested  that  this  Bill  be  tabled  until  appropriate 
hearings  can  be  held. 


ACTION: 

C.  Embrey  to  forward  a  copy  of  this  discussion  and  workshop 
conclusion  to  Congressman  Nichols'  office  for  his  consideration. 

PROFESSIONAL  CERTIFICATION 
FOR  CM  PERSONNEL: 

1.  The  attendees  discussed  the  possibility  of  establishing  an  ADPA 
sanctioned  CM  certification  program  for  CM  personnel.  That  discussion 
centered  on  the  following  key  points/questions: 

a.  Will  certification  prove  to  be  beneficial? 

b.  Should  hardware  CM  be  separated  from  Software  CM  in  the 
certification  process? 

c.  Should  a  series  of  certificates  be  established  to  indicate 
progression  from  the  technician  level  to  a  high  level 
professional? 

d.  Should  a  "Grandfather  clause"  be  invoked  for  current  CM 
professionals  with  X  number  of  years  experience? 
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e.  Who  will  establish  certification  criteria,  and  by  what 
authority? 

2.  It  was  agreed  by  the  attendees  that  a  working  group  should  be 
established  to  develop  a  "strawman"  certification  policy  and  procedures 
document,  to  be  presented  at  the  next  workshop  for  further  discussion. 
C.  Embrey  agreed  to  chair  that  working  group,  which  will  be  composed 


of  the  following  individuals: 
Joseph  J.  Adamo 

Mike  Daniels 

Tony  Darmanin 

Dick  Mooney 

Dick  Thomas 


108  Wimberly 
Rochester,  MI  98064 

The  MITRE  Corporation 
1820  Dolley  Madison  Blvd. 
McLean,  VA  22102 

General  Motors  of  Canada  Ltd. 
Diesel  Division 
P.0.  Box  5160 
London,  Ontario  N6A4N5 
(519)  452-5533 

Control  Data  Corporation 
3101  E.  80th 
Box  609 

Minneapolis,  Minnesota  55440 

FMC  Corporation 
1105  Coleman  Ave. 

San  Jose,  CA 
(408)  289-3973 

TRW 

7600  Colshire  Dr. 

Fairfax,  Va.  22102 
Wl/3530 


Julie  Thomas 


QUESTIONS/DISCUSSIONS 

POSED  BY  THE  ATTENDEES: 

1.  For  proposal  response,  is  Data  Management  considered  part  of  CM? 
Also,  is  it  possible  to  have  standardized  CM  or  DM  wording,  or 
does  each  response  require  complete  or  special  wording? 

•  A  possible  solution  to  proposal  responses  is  to  cite  in-house 
(company)  CM&DM  Standards  and  Procedures.  It  should  be  noted 
that  ADPA  is  currently  promoting  Government  certifi  ation  of 
Contractors  in-house  CM&DM  plans. 

2.  Is  there  a  CM  status  accounting  computer  program  available  for  an 
IBM  PC  that  will  handle  100-300  drawing  end  items  of  1-10 
quantity?  Can  a  copy  be  purchased? 

•  Suggestion  was  to  develop  your  own  software  using  DB-II  or 
R-Base. 

3.  Are  any  aerospace  contractors  having  problems  in  contract 
closeout/fee  negotiations  with  the  number  of  waivers/deviations 
processed  under  MIL-STD-480A? 

t  If  the  contracting  officer  has  signed  the  waiver,  and  the 
deviations  are  approved  by  the  procuring  activity  prior  to 
production,  there  should  be  no  problems. 

4.  What  software/hardware  components  does  the  DOD  define  as 
"firmware"?  If  "firmware"  is  truly  defined,  are  there  any 
specific  DOD-STDs  or  specs  relating  to  the  documentation  of 
firmware? 
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•  MIL-STD-SDS  (proposed)  of  31  August  1983,  Subject:  Defense 
System  Software  Development  defines  firmware  and  how  it  should 
be  documented.  That  standard  is  scheduled  for  implementation 
in  October  1984. 

5.  One  Ada  goal  is  to  encourage  reusable  software  modules.  Is  an 
effort  underway  or  planned  to  implement  a  software  equivalent  of 
"standard  parts"  and  "federal  stock  number"  schemes?  Who  is 
doing  so? 

•  No  one  is  working  directly  on  this  problem.  The  Government 
is  moving  to  defined  modules,  and  there  is  an  Ada  newsletter 
which  will  address  the  problem  in  the  near  future. 

ACTION  ITEM  LIST: 

1.  Mr.  C.  J.  Embrey  will  supply  updated/new  DOD  CM  documents  to  the 
workshop  attendees  for  comment  as  they  become  available. 

2.  Mr.  C.  J.  Embrey  and  the  CM  Certification  Working  Group  will  draft 
a  "strawman"  CM  certification  policy  and  procedures  document  for 
presentation  at  the  next  CM  workshop. 


ROSTER  OF  ATTENDEES 


NAME 

REPRESENTING 

TELEPHONE  NO. 

Joseph  A.  Adamo 

USA  TACOM 

P.0.  Box  383 

Rochester,  MI  48064 

A V  786-6713 
(313)-574-6713 

Barbara  Ankeny 

Ford  Aerospace 

(704)  720-5125 

Charles  H.  Burk 

« 

LTU  Aerospace  &  Defense  Co. 
Vought  Aero  Div. 

Mail  Stop  194-23 

P.0.  Box  225907 

Dallas,  TX  75265 

(214)  266-5633 

CAPT  Tom  Burke,  USN 

NAVSEALOGSUPENGACT/ 

NAVELEX  DET  MECH 

Box  2020 

Mechanicsburg,  Pa.  17055 

(717)  790-2711 

Dan  Burrs 

FMC 

4800  East  River  Rd. 
Minneapolis,  Minn. 

(612)  571-9201 

Charles  Cattaneo 

Martin  Marietta 

P.0.  Box  5837  MP33 

Orlando,  FL  32855 

(305)  356-2395 

Don  Dansbury 

US  Army  Tank-Auto  Cmd. 
Warren,  MI  48090 

AV  786-6220 

David  Ells 

Martin  Marietta 

(303)  977-7783 

Len  Gabour 

Bendix  GSD 

Rt  46 

Teterboro,  N.J.  07608 

(201)  393-3014 

Charles  Gill ett 

Texas  Instruments 
Lewisville,  Texas 

(214)  462-4671 

Michael  J.  Goy 

AFLC-CASC/CBRS 

Federal  Center 

Battle  Creek,  MI  49016 

(616)  962-6511  X9228 

Richard  B.  Heggem 

Westinghouse 

Marine  Division 

(408)  735-2409 

ROSTER  OF  ATTENDEES  (Continued) 


NAME 

REPRESENTING 

TELEPHONE  NO 

Roger  Hietala 

FMC  Corp. 

4800  East  River  Rd. 
Minneapolis,  Minn. 

(612)  571-9201 

Sue  Jensen 

Ford  Aerospace 

(714)  720-6458 

Robert  Keeler 

NAVSEA  Logistics 

Support  Eng.  Activity 

P.0.  Box  2020 
Mechanicsburg,  Pa.  17055 

(717)  790-3887 

John  Kick 

ASD/AWZ 

(513)  255-2687 

WPAFB 

Ohio  45432 

AV  369-9228 

Michael  Long 

E-Systems  Mel  par 

7700  Arl ington  B1 vd. 

Falls  Church,  V A 

Charles  B.  McClure 

Martin  Marietta  Aerospace 
P.0.  Box  179 

Denver,  Colorado 

(303)  977-7898 

Jim  Miller 

Lockheed  Calif.  Co. 

P.0.  Box  550 

Burbank,  CA 

D/72-72  B90-4 

(818)  847-9301 

Dick  Mooney 

Control  Data  Corp. 

3101-E .  80th 

Box  609 

Minneapolis,  Minn.  55440 

(612)  853-4869 

Ray  Nichols 

AT&T 

(919)  279-7115 

Jim  Remiker 

General  Dynamics 

Convair  Div.,  MZ23-6060 

P.0.  Box  85357 

San  Diego,  CA  92138 

(619)  573-8588 

J.  D.  Richardson 

5203  Leesburg  Pike 

Suite  1403 

Falls  Church,  VA  22041 

ROSTER  OF  ATTENDEES  (Continued) 


NAME 

REPRESENTING 

TELEPHONE  NO 

Hal  Rowland 

Sundstrand  Aviation 

4747  Harrison  Ave. 
Rockford,  IL  61101 

(815)  226-7445 

Art  Rulon 

USArmy  DARCOM  (MRSA) 
Lexington,  KY 

(606)  293-3415 

Richard  P.  Sanczel 

Martin  Marietta 

P.0.  Box  5837  MP33 

Orlando,  FL  32855 

(305)  356-2395 

Ron  Schrage 

ASD/XRJ 

Wright-Patterson  AFB 

OH  45433 

1-513-255-6651 

John  Scotton 

USA  CECOM 

Ft.  Monmouth,  N.J. 

(201)  532-3236 

A.  D.  Signor 

NAVSEASYSCOM 

NSWSES  Code  4330 

Port  Hueneme,  CA  93043 

(805)  982-5844 

Dave  Smock 

NAVSURWPNCEN 

White  Oak 

Silver  Spring,  MD  20910 

(202)  394-1573 
AV  290-1573 

Sue  Swanson 

Texas  Instruments 

Home  Address: 

2012  Ports  O'Call 

Plano,  Texas  75075 

(214)  995-6843 

Ed  Sweetman 

The  Bendix  Corp. 

Guidance  Systems  Div. 
Route  46 

Teterboro,  N.J.  07608 

(201)  393-2929 

Dick  Thomas 

FMC  Corp. 

San  Jose,  CA 

(408)  289-3973 

Julie  Thomas 

TRW 

7600  Colshire  Dr. 

McLean,  VA  22102 

Wl/3530 

(703)  734-6240 
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Electronic  &  Support  Serv. 

Joint  Tactical 

Comm.  Office  (TT-LD-CM/DM) 


TELEPHONE  NO 
(817)  633-2593 
(201)  532-7731 


AVRADA,  ATTN:  SAVAA-SIPE  (201)  544-2701 
Ft.  Monmouth,  N.J. 


Workshop  #5 


COMPUTER  SOFTWARE 


(This  workshop  is  combined  with  Workshop  #4) 
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WORKSHOP  #6 

ENGINEERING  DATA  AUTOMATION 


SUMMARY 


The  Engineering  Data  Automation  Workshop  is  the  potpourri  of  engineering 
data.  Automation  of  engineering  data  goes  from  the  pure  computer  program  to 
complex  management  schemes.  The  workshop  did  not  attempt  to  cover  it  all  in 
the  short  time  allotted,  but  did  brush  upon  repositories,  automation  of  the 
Acquisition  Management  Systems  and  Data  Requirements  Control  List  (AMSDL)  and 
technical  documentation. 

Participation  in  this  year's  workshop  was  in  balance  with  the  participa¬ 
tion  in  the  overall  symposium.  There  were  56  participants  consisting  of  38 
from  industry  and  18  from  various  Government  components.  The  Government  parti¬ 
cipants  were  limited  to  Army,  Navy,  Air  Force  and  National  Security  Agency. 

Mr.  James  D.  Richardson  from  DMSSO  was  called  on  to  give  the  workshop  the 
latest  status  of  DoD  activities  in  the  automation  world.  Mr.  Richardson  said 
the  DoD  efforts  are  centered  in  three  basic  areas  and  each  is  considered  a 
pilot  program  for  that  DoD  component.  The  first  program  is  the  ARPS  program 
which  is  under  guidance  of  the  Army.  It  is  a  fully  automated  publishing 
program  and  it  has  been  in  operation  for  approximately  a  year.  This  program 
is  expected  to  be  a  full  system  with  a  CAD  interface.  The  second  area  is 
ur  r  Air  Force  sponsorship  and  is  called  ATOS.  It  is  ai<  automated  technical 
c  er  system.  The  prototype  is  nearing  completion  and  the  production  system 
expected  to  begin  in  June  1984.  The  third  system  is  under  the  sponsorship 
of  the  Navy  and  is  known  as  the  NTIPS.  This  program  has  had  its  ups  and  downs 
due  to  funding  problems.  At  this  time  there  is  no  specific  system  that  you 
can  literally  put  your  hands  on. 

Other  programs  ongoing  under  DoD  cognizance  include  a  full  digitized  data 
base.  It  is  currently  under  contract  and  is  due  to  be  delivered  in  18  months. 
Few  details  were  given  on  this  system. 

The  final  major  mechanization  efforts  of  DoD  are  centered  around  the  re¬ 
positories.  The  automation  of  the  repositories  has  been  mandated  by  Secretary 
of  Defense  Weinberger,  and  Congress  has  been  advised  that  DoD  is  programming 
to  have  the  repositories  automated  by  1989.  There  are  12  Army  and  Air  Force 
repositories  that  are  scheduled  for  automation  under  a  joint  Army/AF  specifica¬ 
tion.  The  RFP  has  been  on  the  street  approximately  45  days  and  responses  are 
due  within  the  next  couple  of  weeks.  Awards  of  the  contract  should  follow 
shortly  thereafter. 

DLA  has  four  respositories  that  require  automation.  Its  program  will  be 
conducted  in  two  phases.  The  first  phase  involves  the  acquisition  of  four 
semiautomatic  Infonetic  systems.  The  semiautomatic  systems  will  be  developed 
into  a  full  system  during  the  second  phase  by  conversion  on  a  hit  to  hit 
basis.  This  is  interpreted  to  mean  that  only  those  documents  that  are  re¬ 
quested  will  be  digitized.  Therefore,  DLA  is  not  expected  to  digitize  the 
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full  repository,  but  only  new  and  actively  used  documentation.  New  documents 
will  be  digitized  prior  to  entry  in  the  repository.  The  Naval  Air  Technical 
Services  repository  at  Philadelphia  is  scheduled  to  be  automated  within  the 
next  12  months.  Competition  was  between  Infonetics  and  DESRID,  and  recently 
the  contract  was  awarded  to  Infonetics. 

A  presentation  was  given  by  Darrel  Christenson  on  the  use  of  bar  coding 
for  such  things  as  inventory  control,  document  tracking,  tool  tracking  and 
materials  requirements  planning. 

A  discussion  on  what  ADPA  could  do  to  assist  the  DoD  in  future  and  current 
automation  programs  was  held.  An  interest  was  shown  in  development  and  appli¬ 
cation  of  the  GENCODE  and  IGES.  As  a  result  of  the  discussion,  the  chairman 
will  establish  a  liaison  with  DMSSO  and  request  all  proposed  new/revised  docu¬ 
ments  concerning  digitization  of  documentation  be  made  available  to  the  Engin¬ 
eering  Data  Automation  committee  for  review  and  comment.  The  first  documents 
to  be  requested  will  be  the  GENCODE  and  IGES.  Interested  attendees  will  be 
forwarded  copies  of  these  documents  for  comment  upon  receipt. 

During  the  discussion  it  was  noted  that  lack  of  standardization  of  de¬ 
fining  data  made  it  difficult  to  automate  the  acquisition  procedures.  It  was 
suggested  that  the  committee  develop  selected  data  item  descriptions  to  define 
the  specific  requirements  for  digitization  of  engineering  data.  Attendees  of 
the  workshop  will  be  contacted  after  the  meeting  on  an  individual  basis  to  de¬ 
termine  the  requirements  and  capabilities  necessary  to  improve  the  engineering 
data  automation  program  associated  with  DoD. 

Based  on  the  enthusiasm  shown  in  the  workshop  this  year,  it  is  expected 
that  a  meaningful,  ongoing  program  will  be  presented  to  the  annual  meeting 
next  year. 
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26TH  ANNUAL  MEETING 

ATTENDANCE  ROSTER 
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JOSEPH  J.  ADAMO 
USA.  TACOM 
MECHANICAL  ENGINEER 
WARREN  MI  48090 


E.  W.  ANDERSON.  JR 
MARTIN  MARIETTA 
SR  STAFF  ENGINEER 
PO  BOX  179 

DENVER  CO  80201 


HERBERT  T.  ASHLEY 

US  NAVY.  NSWSES 

GENERAL  ENGINEER 

NSWSES  CODE  5122 

PORT  HUENEME  CA  93043 


ED  BASTEK 

MOTOROLA  INC,  GEG 

MGR.  CONFIG/DATA  MGT 

8201  E.  MCDOWELL  RD,  MD  T23W 

SCOTTSDALE  AZ  85252 


CURTIS  P.  BAUER 

AMCCOM 

COMMANDER 

ATTN:  DRSMC /TSC /E ( A ) 

A.  P  G.  MD  21010 


VERNON  C.  BEONARD 

TACOM 

DATA  MGT 

37605  MT  CLEMENS 

WARREN  MI  48045 


CAPT  DAVID  L.  BOSLAUGH 
NAVAL  MATERIAL  COMMAND 
EMBEDDED  COMPUTER  PROGRAMS. DIR 
CODE  MAT  08 Y 

WASHINGTON  DC  20360 


ANTHONY  J  BRADDOCK 
THE  BDM  CORPORATION 
PROGRAM  MANAGER-DARCOM 
7915  JONES  BRANCH  DRIVE 
MCLEAN  VA  22102 


C  H.  (JERRY)  BURK 
LTV  AEROSPACE  &  DEF  CORP 
TECHNICAL  PROJECT  MANAGER 
PO  BOX  225907 

DALLAS  TX  75265 


JAMES  V  BURLEIGH 
BOEING  MILITARY  AIRPLANE  CO 
DRAFTING  STDS  SUPERVISOR 
2110  S  WATER 

WICHITA  KS  67213 


DAN  BURRS 
FMC  CORPORATION 
SR  STANDARDS  ENGINEER 
4800  EAST  RIVER  ROAD 
FRIDLEY  MN  55432 


SAMUEL  ALVINE,  JR. 
SINGER-KEARFOTT  DIV 
SUPERVISOR,  SPEC.  ENGRG 
150  TOTOWA  RD  /MS12A36 
WAYNE  NY  07470 


B.  J.  ANKENY 

FORD  AEROSPACE  &  COMM  CORP 
NEWPORT  BEACH  CA  92660 


HERBERT  L  ATKINS 

EG&G  WASH  ANALY  SERV 

HEAD  DATA  MGMT  DEPT  CODE  348 

2150  FIELDS  ROAD 

ROCKVILLE  MD  20850 


ARNOLD  M  BATINA 
BALL  AEROSPACE  SYS  DIV 
MANAGER,  ENG 'G  SERVICES 
PO  BOX  1062 

BOULDER  CO  80306 


IVAN  L.  BENGTSON 
NSA 

ENGINEERING  MGR 

9800  SAVAGE  ROAD 

FT  MEADE  MD  20755 


CHARLES  J.  BORUM 

USA  MISSILE  COMMAND 

COMMANDER 

ATTN:  DRCTM/PE/C 

REDSTONE  ARSNL  AL  35809 


EMMETT  G.  BOYD 

LITTON  SYSTEMS,  INC 

SUPR,  TECH  PUB'S 

5500  CANOGA  AVE 

WOODLAND  HILLS  CA  91365 


RALPH  P  BROWN 
XMCO 

8200  GREENSBORO  DR.  ,  #801 
MCLEAN  VA  22102 


CAPT  THOMAS  J.  BURKE 
NAVSEA 

COMMANDING  OFFICER,  LOG  SUP 
PO  BOX  2020 

MECHANICSBURG  PA  17055 


LORNA  BURNS 
HUGHES  AIRCRAFT  CO 
BLDG  C2  MS  B108 
PO  BOX  1042 

EL  SEGUNDO  CA  90245 


RAY  CALHOUN 

TEXAS  INSTRUMENTS  INC 

DATA  MANAGER 

BOX  226015  MS  384 

DALLAS  TX  75266 


JOHN  P.  CAMPBELL 
BOEING  MILITARY  AIRPLANE 
PUB  TRNG  3.  RES  AUT  MGR 
PO  BOX  7730 

WICHITA  KS  67277 


MR  ROBERT  H  CARRIER 
RAYTHEON  COMPANY 
MANAGER.  PRODUCT  SUPPORT 
BOSTON  POST  ROAD 
WAYLAND  MA  01778 


CHARLES  A.  C ATTANEO 
MARTIN  MARIETTA  CORPORATION 
MANAGER  CONFIG  &  DATA  MGT 
P.  0.  BOX  5837,  MP-33 
ORLANDO  FL  32855 


JERRY  F.  CAZZELL 
USAF 

BRANCH  CHIEF-ENG  DATA 
WPAFB  OH  45433 


ANGELO  CHRIST I ANO 
OR I  INC. 

SENIOR  PROGRAM  DIRECTOR 
1725  JEFF  DAVIS  HWY,  #901 
ARLINGTON  VA  22202 


LARRY  A  CISKOWSKI 
BOEING  COMPANY 
CORP  DRAFTING  STANDARDS 
P  0  BOX  3999  M/S  8C-53 
SEATTLE  WA  98124 


JOSEPH  M.  CONNELLY 
MNEMOS  SALES  &  CUST  SRVC 
FEDERAL  REGION  MGR 
218  N.  LEE  STREET 
ALEXANDRIA  VA  22314 


LESTER  E.  CROWLEY 
MARTIN  MARIETTA  CORP 
CDM  ADMINISTRATOR /ENGINEER 
103  CHESAPEAKE  PARK  PLAZA 
BALTIMORE  MD  21220 


DON  DANSBURY 

US  ARMY  TANK  AUTOMOTIVE  COMND 

SR  PROJECT  ENGR 

2278  KETTLE  ST 

TROY  MI  48084 


CURT  DAVIS 

ROLM  CORPORATION 

ENGINEERING  SERVICES  MANAGER 

ONE  RIVER  OAKS  PLACE 

SAN  JOSE  CA  95134 


DONALD  C  DEROSIA 
GENERAL  ELECTRIC  COMPANY 
1285  BOSTON  AVENUE 
BRIDGEPORT  CT  06602 


PHILLIP  CARDON 

DRSTA-HC 

TACOM 

DIRECTORATE  OF  PROC  AND  PROD 
WARREN  MI  48090 


JAMES  H  CASEY 

ARMY  AVIATION  SYS  CMD 

3900  BOWEN 

ST  LOUIS  MO  63116 


ROY  J.  CAZARES 
SA-ALC /MMEDB 

SUPR.  AEROSPACE  ENGR  TECH 

7011  FOREST  PARK 

SAN  ANTONIO  TX  78240 


ROBERT  H  CHAP DELAINE 
HAMAN  AEROSPACE  CORP 
MGR-SERVICE  PUBLICATIONS 
OLD  WINDSOR  ROAD 
BLOOMFIELD  CT  06002 


JERRY  CICHOWICZ 

US  ARMY 

SUPER  GEN  ENGR 

6113  JOHNNYCAKE  RD 

BALTIMORE  MD  21207 


ROBERT  COLLINS 
FMC  CORPORATION 
STAFF  ENG 

1105  COLEMAN  AVENUE 

SAN  JOSE  CA  95108 


PAUL  T  COURTOGLOUS 
ESD/AFSC 

USAF/TOSC,  HANSCOM  AFB 
CHIEF  .CONFIG  &  DATA  MGMT  DIV 
BEDFORD  MA  01731 


JOHN  CURTIN 

KOLLSMAN  INSTRUMENT  CO 
SUPERVISOR.  TEC  PUBS  «<  DATA 
220  DW  HIGHWAY  SO 
MERRIMACK  NH  03054 


TONY  DARMANIN 
GM  OF  CANADA,  LTD 
PO  BOX  5160 

LONDON,  ONTARIO  CANADA 
N6A  4N5  00000 


E.  W.  DEADWEYLER 
TEXAS  INSTRUMENTS 
MS  3128 
PO  BOX  660246 

DALLAS  TX  75266 


KENNETH  L.  DION 
GEN  DYNAMICS  LAND  SYS 
PUBLICATION  SUPERVISOR 
PO  BOX  527 

WARREN  MI  48090 


MARLENE  S  DOWDELL 
TELEDYNE  CAE 
1330  LASKEY  RD 
PO  BOX  6971 

TOLEDO  OH  43612 


ALVIN  M  EBELING 
ABA  ELECTROMCHNL  SYS,  INC 
MGR.  ENGINEERING  SUPPORT 
PO  BOX  500 

PINELLAS  PARK  FL  32490 


CHARLES  J.  EMBREY 
MITRE  CORPORATION 
M/S  W45S 

1820  DOLLY  MADISON  BLVD 
MCLEAN  VA  22102 


ANTHONY  M  FAILS 

LOCKHEED  MISSILES  S<  SPACE 

2124  E.  ST.  ELMO  ROAD 

T2-32.  BLDG  30E 

AUSTIN  TX  7S745 


KEITH  E  FOSTER 
RAYTHEON  COMPANY 
C/DM  MANAGER 
HARTWELL  ROAD 

BEDFORD  MA  01730 


LEONARD  GABOUR 
BENDIX  CORPORATION 
GSD  -  CONFIGURATION  MGR 
RT  46 

TETERBORO  NJ  07608 


OTTO  F.  GARRETT 
INTERNATIONAL  LASER  SYS.  INC 
DESIGN  SUPPORT  MANAGER 
3404  N.  ORANGE  BLOSSOM  TRAIL 
ORLANDO  FL  32804 


CHARLES  C.  GILLETT 

TEXAS  INSTRUMENTS 

CONFIG  MGR 

2704  LEMMONTREE 

PLANO  TX  75074 


MR  LINUS  L  GLOWIENKA 
KEN  COOK  COMPANY 
CONTRACT  ADMINISTRATOR 
9929  WEST  SILVER  SPRING  ROAD 
MILWAUKEE  WI  53225 


MR  THEODORE  L  GOLMIS 
HUGHES  AIRCRAFT  CO 
BLDG  604  M/S  F-122 
P.  O  BOX  3310 

FULLERTON  CA  92634 


MICHAEL  J  GOY 

AFLC-CASC /CBRSD 

SR. ,  EQUIP  SPECIALIST 

FEDERAL  CENTER 

BATTLE  CREEK  MI  49016 


DARLENE  DUERDEN 
R  &  D  CENTER 
DATA  MANAGEMENT  OFFICE 
FT  BELVOIR  VA  22606 


DAVID  B.  ELLS 

MARTIN  MARIETTA 

MGR,  PEACEKEEPER  CM 

4685  E.  LAKE  AVE 

LITTLETON  CO  80121 


JOHN  E  ENDICOTT 
GENERAL  DYNAMICS/CONVAIR 
MS  23-6290 
PO  BOX  80847 

SAN  DIEGO  CA  92112 


MR  CHARLES  D  FISHER 
RCA 

GOVT  COMM  SYS 

BUILDING  10-6-2 

CAMDEN  NJ  08102 


ROBERT  0  FRIGON 
VSE  CORPORATION 
VICE  PRESIDEN. 

2550  HUNTINGTON  AVE 
ALEXANDRIA  VA  22303 


DAVID  L.  GAM AC HE,  JP 
USA,  TACOM 
MECHANICAL  ENGINEER 
DRSTA-ZEA 

WARREN  MI  48090 


PATRICIA  A  GILES 

DEPT  OF  DEFENSE 

TECHNICAL  DATA  MGT  OFFICER 

9800  SAVAGE  ROAD 

FT  MEADE  MD  20755 


CLELL  W.  GLADSON 
NAVAL  OCEAN  SYS  CNTR 
HD,  SOFTWARE  QUALITY  MGT 
271  CATALINA  Bl.VD  ,  CODE  914 
SAN  DIEGO  CA  92152 


GERRY  GODBURN 
ENSIGN  BICKFORD,  CO. 
SUPERVISOR,  QUALITY  ENG 'G 
660  HOPMEADOW  ST 
SIMSBURY  CT  06070 


EDWARD  0.  GONZALEZ 

AIR  LOGISTICS  CENTER 

AERO-SPACE  ENGR  TECH 

1614  W  CRAIG  PLACE 

SAN  ANTONIO  TX  78201 


!  GAETANO  C.  GRANDE 
RAYTHEON  COMPANY 
MGR,  DATA  MGT 
HARTWELL  ROAD 
BEDFORD  MA 


01730 


PAT  GREENWOOD 
HERCULES  INC 
PROJECT  ENGINEER 
PO  BOX  98 

MAGNA  UT  84044 


ROGER  HA I  TALA 
FMC  CORPORATION 
4800  E  RIVER  ROAD 
FRIDLEY  MN  55432 


JACK  HAMILTON 
RAYTHEON  CO. 

SR  ENGINEER-PUBS 
HARTWELL  RD. 

BEDFORD  MA  01730 


JOHN  R  HART 

BOEING  AEROSPACE  COMPANY 
PO  BOX  3999 
M/S  8K-61 

SEATTLE  WA  98124 


D  HARTZELL 

NATIONAL  SECURITY  AGENCY  S243 
CHIEF  CSS 

FT  G  G  MEADE  MD  20755 


R.  B.  HEGGEM 

WESTINGHOUSE  ELECTRIC  CORP. 
401  E.  HENDY  AVENUE 
PO  BOX  499  < M/S  EW-1) 
SUNNYVALE  CA  94088 


THOMAS  J  HENDERSON 
FORD  AEROSPACE  &  COMM  CORP 
BUSINESS  SYSTEMS  SPECIALIST 
3939  FABIAN  WAY  MS  A45 
PALO  ALTO  CA  94303 


ROBERT  E  HUMMEL 
HONEYWELL,  INC 

CONFIGURATION  MGT  SPECIALIST 
13350  US  HWY  19  S  ,  MS  456-4A 
CLEARWATER  FL  35546 


LIONEL  T.  HURST 
GM  OF  CANADA.  LTD 
1991  OXFORD  STREET,  EAST 
LONDON,  ONTARIO  CANADA 
N6A  4N5  00000 


CAPT  NELSON  P.  JACKSON 
USN,  RET  ADPA 
STE  900 

1700  N  MOORE  ST 
ARLINGTON  VA  22209 


ALAN  JOHNSON 

BOEING  COMPUTER  SERVICES 
ANALYST 

3801  S.  OLIVER  < 

WICHITA  KS  67206  ' 


DENNIS  HAGLER 

TEXAS  INSTRUMENTS 

DRAFTING  STANDARD  COORDINATOR 

3823  N  MAGNOLIA  CT 

FLOWER  MOUND  TX  75028 


MICHAEL  A.  HALVERSON 
DATA  MGT  ELECTRO  OPTICS  DIV 
TEXAS  INSTRUMENTS  INC 
PO  BOX  660246 

DALLAS  TX  75266 


JEAN  HARMAN 
NAVSEA 

DIR,  DOD  STDZN  PROG  DOCS  DIV 
NAVY  DEPT,  SEA55Z3 
WASHINGTON  DC  20362 


ROBERT  E  HARTMAN 
TRW 

CONFIG  CONTROL  ENGR 
PO  BOX  1310,  M/S  502/1999 
SAN  BERNARDINO  CA  92402 


HERBERT  HEDSTROM.  JR 
SANDERS  ASSOCIATES,  INC 
PRINCIPAL  ENG INGEERING  WRITER 
95  CANAL  STREET.  CS  2004 
NASHUA  NH  03061 


ROBERT  R.  HEGLAND 
USA  COMPUTER  SYSTEMS  CMD 
SENIOR  COMPUTER  SPECIALIST 
FT  BEL VOIR  VA  22060 


JOHN  HORNICK 
US  ARMY  AMCCOM 
DATA  MGMT.  SPEC. 

3509-3ST  A 

EAST  MOLINE  IL  61244 


MICHAEL  HURN 
952  LONGHORN 

PLANO  TX  75023 


CLIFFORD  R.  HUTCHISON 
ELECTRONIC  &  SUPP  SRVS,  INC 
SUPERVISOR  TECHNICAL  ILLUS. 
1128  107TH  STREET 
ARLINGTON  TX  76011 


S.  L.  JENSEN 

FORD  AEROSPACE  &  COMM  CORP 
NEWPORT  BEACH  CA  92660 


RICHARD  K.  JOHNSON 

TALLEY  OF  ARIZONA 

MANAGER  ENGINEERING  SERVICES 

3500  N.  GREENFIELD 

MESA  AZ  85205 


MIRIAM  S  JONES 
USAF 

DATA  MANAGEMENT 
<MMMRF  > 

ROBINS  AFB  GA  31098 


ROBERT  B  JORDAN 

USA  TACOM 

TECH  DATA  DIV 

28251  VAN  DYKE  AVENUE 

WARREN  MI  48090 


JOHN  KICAK 

HQ.  DARCOM 

S.  GENERAL  ENGINEER 

5001  EISENHOWER  AVENUE 

ALEXANDRIA  VA  22333 


NORMAN  W  KINDER 
BOEING  AEROSPACE  CO  ENGR  STD 
P  O  BOX  3999  2-3623  MS8C-53 
SEATTLE  WA  98124 


RICHARD  E  KNOB 

SPERRY  RAND  CORP 

SPERRY  GYROSCOPE  DIV 

3311  AUSTIN  AVE 

WANTAGH  NY  11793 


DONALD  KOZAK 
DOD 

ENGINEERING  SPECIALIST 

9800  SAVAGE  RD 

FT  GEORGE  MEADE  MD  20755 


FREDERICK  B  LEWIS 
HUGHES  AIRCRAFT  CO 
MANAGER  BUSINESS  PLANNING 
2000  E.  IMPERIAL  HWY,  R1/D405 
EL  SEGUNDO  CA  90245 


GARNET  M  LIEBLICH 

GLOBAL  ENGRG  DOCUMENTATION  SER 

EXECUTIVE  VICE  PRESIDENT 

2625  S  HICKORY  ST 

SANTA  ANA  CA  92707 


DR.  LARRY  M  LINDLEY 
NAVY  AVIONICS  CENTER 
PROGRAM  MANAGER 

EMBEDDED  COMP  &>  TACTICAL  SFTWR 
INDIANAPOLIS  IN  46206 


JOHN  W  LOGSDON 
CRANE  ARMY  AMMUN.  ACTIVITY 
MECHANICAL  ENGRG  TECH  ( DRAFTG ) 
ENGINEERING  DIRECTORATE 
CRANE  IN  47522 


MICHAEL  R  LONG 

E-SYSTEMS  INC  MELPAR  DIV 

MANAGER.  CONFIG  MGT 

7700  ARLINGTON  BLVD 

FALLS  CHURCH  VA  22046 


RAYMOND  L  JONES 
NAVAL  EOD  FACILITY 
MECHANICAL  ENGINEERING  TECH 
INDIAN  HEAD  MD  20640 


COLM  KEANE 

DEPT  OF  NAT 'L  DEF,  OTTAWA 
101  COLONEL  -  BY  DRIVE 
OTTAWA  K1A  0K2 
CANADA  00000 


ROBERT  J.  KICK,  JR 

4701  SEVILLE  DR 

ENGLEWOOD  OH  45322 


DR.  DOUGLAS  KNIFFEN 

WEST I NGHQUSE  ELECTRIC  CORP 

COL.  CORP  CENT  20,  MS  2410 

1015  NICODEMUS  ROAD 

RE I STERSTOWN  MD  21136 


WARREN  KNUTSON 

PACIFIC  CAR  &  FOUNDRY  COMPANY 
TECHNICAL  PUBS,  MANAGER 
1400  NORTH  4TH  STREET 
RENTON  WA  98055 


CARL  D.  KREBS 
AT8cT  CONSUMER  PRODUCTS 
SENIOR  ENGINEER 
2400  REYNOLDA  ROAD 
WINSTON-SALEM  NC  27106 


GEORGE  L.  LEWIS 
NORTHROP  CORPORATION 
MGR.,  CONTRACT  DATA  REQT'S 
15150  MAGNOLIA  #270 
WESTMINSTER  CA  92683 


JEROME  H  LIEBLICH 

GLOBAL  ENGRG  DOCUMENTATION  SER 

PRESIDENT 

2625  S  HICKORY  3T 

SANTA  ANA  CA  92707 


JOSEPH  W.  LLOYD 
I  HQ,  DARCOM  (DRCSM-SA) 
i  DEP  DIR  FOR  SUPP  UPS 
i  5001  EISENHOWER  AVE 

ALEXANDRIA  VA  22333 


,  J  E  LONG 

AEROJET  TACTICAL  SYS  CO 
!  MGR  ENGRNG  SERVICES 
|  PO  BOX  13400 

SACRAMENTO  CA  95813 


SUSANO  MASCORRO 
USAF 

CHIEF,  F100  CONFIG  MGT  DIV 
4371  POWDER  HORN  DRIVE 
DAYTON  OH  45432 


M.  L  MAYES 
GENERAL  DYNAMICS 
CONFIGURATION  CONTROL  SPCLST 
PO  BOX  748 

FORT  WORTH  TX  76101 


CHARLES  B.  MCCLURE  M#  D2400 
MARTIN  MARIETTA  CORPORATION 
DENVER  DIV 
P  0  BOX  179 

DENVER  CO  80201 


LOREN  R.  MELTON 
NSDSA 

SUPERVISOR  SPEC  EDITOR 
NSWSES,  CODE  5730 
FT  HUENEME  CA  93043 


JOE  W  MEREDITH 
NEWPORT  NEWS  SHIPBUILDING 
MANAGER .  MARKE  T I NG 
4101  WASHINGTON  AVE 
NEWPORT  NEWS  VA  23607 


HUGH  A  MILLER 

11305  SHIRL  COURT 

CLINTON  MD  20735 


DICK  MOONEY 

CONTROL  DATA 

MGR-ENG  SERVICES 

3101  E  80TH  ST  BOX  609 

BLOOMINGTON  MN  55440 


VINCENT  J  MORAVEK 
MARTIN  MARIETTA  AEROSPACE 
MANAGER,  ENGRG  SUPPORT  SRVCS 
PO  BOX  179,  MAIL  #  0438 
DENVER  CO  80201 


DENNIS  MOTTA 

TEXAS  INSTRUMENTS,  INC 

DATA  MGR 

2612  KIMBERLY  CT 

PLANO  TX  75075 


GORDON  F  NEARY 
MCDONNELL  DOUGLAS  CORPORATION 
DEPT  201  BLDG  33  ROOM  571 
P  O  BOX  516 

ST  LOUIS  MO  63166 


BURT  NEWLIN 
DMSSO 

CAMERON  STATION 
ALEXANDRIA  VA  22314 


BRUCE  F.  OGDEN 
FINKELSTEIN  ASSOC. ,  INC 
DIR  OF  OPERATIONS 
15932B  SHADY  GROVE  RD 
GAITHERSBURG  MD  20877 


CHARLES  MCARTHUR 
AERONAUTICAL  SYSTEMS  DIV 
INTEGRATED  LOG  SUPPT  DIV 
ATTN:  ASD-ALX 

WPAFB  OH  45433 


EDWARD  R.  MCINTYRE 
NSA 

MANAGER  ENGINEERING 

9800  SAVAGE  ROAD 

FT  MEADE  MD  20755 


SUSIE  MEND I OLA 

KELLY  AFB 

127  E.  MISTLETOE 

SAN  ANTONIO  TX  78212 


CHARLES  A.  MILLER 
FINKELSTEIN  ASSOC. ,  INC 
PROJECT  MANAGER 
15932B  SHADY  GROVE  RD 
GAITHERSBURG  MD  20877 


JAMES  A  MILLER 

LOCKHEED  CALIF  CO 

MGR  SYS  &  PROC,  DEPT  72-72 

PO  BOX  551,  BLDG  90  P/A-l 

BURBANK  CA  91520 


JOHN  L  MOORE 

MARE  ISLAND  NAVAL  SHIPYARD 
DESIGN  DIVISION  CODE  244  11 
VALLEJO  CA  94592 


MELANIE  MORTON 
DEPARTMENT  OF  DEFENSE 
TDMO 

9800  SAVAGE  RD,  CODE  R16 
FT  MEADE  MD  20755 


RONALD  T  NAVE 
EMERSON  ELECTRIC  CO 
STANDARDS  &  PROCEDURES  SPLST 
8100  W  FLORISSANT  AVE,  ST  2788 
ST  LOUIS  MO  63136 


EMIL  NELILLO 
ITT  DCD 

CONFIG  MGT  SPECIALIST 
492  RIVER  RD 

MUTLER  NJ  07110 


R.  L.  NICHOLS 
AT&T  TECHNOLOGIES,  INC 
DEPARTMENT  CHIEF 
PO  BOX  20046 

GREENSBORO  NC  27420 


MARTIN  OLSON 

APPLIED  TECHNOLOGY,  INC 

PRESIDENT 

7435  BALLSTON  BLVD 
SPRINGFIELD  VA  22153 


ROBERT  W.  ORLANDO 

LEAR  SIEGLER,  INC 

ASTRONICS  DIV,  CONFIG  MGMT  AN 

3400  AIRPORT  AVE 

SANTA  MONICA  CA  90406 


GARTH  H  PAYNE,  JR 
FMC  CORPORATION 
MGR,  LOGISTICS  SUPPORT 
1105  COLEMAN  AVE,  BOX  1201 
SAN  JOSE  CA  95108 


JAMES  PRESTON 
TENNECO,  INC 
STAFF  ENGINEER 
PO  BOX  2511 

HOUSTON  TX  77001 


MARIO  RAMIEZ 
USAF 

CHIEF  LOGISTICS  PROJECTS  OFCER 
WPAFB  OH  45433 


MARVIN  L.  REEVES 

TEXAS  INSTRUMENTS 

CONTRACT  DATA  MGR 

2501  S  HWY  121 

LEWISVILLE  TX  75067 


ELLWOOD  H.  RICHARDSON 
MARTIN  MARIETTA  AEROSPACE 
SUPERVISOR,  ENGR.  PROCEDURES 
P.  O.  BOX  179,  MN  0438 
DENVER  CO  80201 


RICHARD  ROBINSON 
PACIFIC  CAR  FOUNDRY  CO. 
ILS  MANAGER 
1400  NORTH  4TH  ST. 

RENTON  WA  98055 


HAL  E.  ROWLAND 

SUNDSTRAND  AVIATION  OPERATIONS 
CONTRACT  DATA  MANAGER 
4747  HARRISON  AVENUE 
ROCKFORD  IL  61101 


ART  RULON 

US  ARMY  DARCOM 

MRSA,  CHF  TECH 'L  PUBS. 

ATTN  DRXMD-MP 

LEXINGTON  KY  40511 


R  SANCZEL 

MARTIN  MARIETTA  AEROSPACE 
MGR  CONFIGURATION  &  DATA  MGT 
PO  BOX  5837,  MP  33 
ORLANDO  FL  32855 


MR  BURTON  G  SCHAEFER 
PITNEY  BOWES 

MANAGER,  ENG  'G  TECH  OPERATIONS 
380  MAIN  AVE,  PO  BOX  6050 
NORWALK  CT  06852 


DAVE  PATTERSON 
GENERAL  MOTORS 
CHEVROLET  MOTOR  DIVISION 
30007  VAN  DYKE  AVE,  2ND  FLR 
WARREN  MI  48090 


W  SCOTT  POLLAND,  JR 
GTE  GOV'T  SYSTEMS  CORP 
DIVISION  DATA  MGR 
100  FERGUSON  DRIVE 
MOUNTAIN  VIEW  CA  94039 


ROBERT  B.  QUILLEN 
HONEYWELL 

MGR.  ,  LOGISTICS  SERVICES 
13476  HACIENDA  DRIVE 
LARGO  FL  33544 


BOB  R  RAMSEY 

FORD  AEROSPACE  COMM  CORP 
AERONUTRONIC  DIVISION 
PO  BOX  A  FORD  RD 
NEWPORT  BEACH  CA  92663 


MR  JAMES  REMIKER 
GENERAL  DYNAMICS/CONVAIR 
CHF,  CONFIG  MGT  REQ  &  ID 
5001  KEARNY  VILLA  ROAD 
SAN  DIEGO  CA  92138 


JAMES  D.  RICHARDSON 
DMSSO 

5203  LEESBURG  PIKE 
SKYLINE  PLACE  2,  STE  1403 
FALLS  CHURCH  VA  22041 


A  G  ROWE 

LOCKHEED  GEORGIA  CO 
SCIENTIST,  DEPT  72-16,  Z  399 
86  SOUTH  COBB  DRIVE 
MARIETTA  GA  30063 


SHIRLEY  A.  RUDDUCK 
7671  SOMERVILLE  DR 
HUBER  HEIGHTS  OH  45424 


OSCAR  C.  SAGAHON 
NORTHROP 

MGR,  DATA  &  CORRESPD  MGT 

540  CALLE  MAYOR 

REDONDO  BEACH  CA  90277 


R.  G.  SARKIES 
BOEING  AEROSPACE  CO 
MGR-PBL I C/TRNG  RESEARCH 
PO  BOX  3999,  MS  82-91 
SEATTLE  WA  98124 


VINCENT  J  SCHENO 
US  ARMY  ARRADCOM 
CHIEF  CAD-TD/CM  BRANCH 
DRDAR-TSC-E 

ABERDEEN  PG  MD  21010 


RAYMOND  SCHMITT 

SINGER  CO,  KEARFOTT  DIV 

MGR,  SPEC'S  ENG  'G  DIV 

150  TOTOWA  ROAD 

WAYNE  NJ  07470 


JOHN  L.  SCOTTON,  JR 
HG,  USA  COMM  ELEC  CMD 
ATTN  DRSEL-ME-LE 
HG  USA  ARMY  CECOM 
FT  MONMOUTH  NJ  07703 


JOHN  A.  SHASTEEN 
HONEYWELL,  INC 

CONFIGURATION  MGT  SPECIALIST 
13350  US  HWY  19  S.  .  MS  456-4A 
CLEARWATER  FL  33546 


ALLAN  D  SIGNOR 
US  NAVAL  SEA  SYS  CMD 
CONFIG  DATA  MGR 
PO  BOX  296 

PORT  HUENEME  CA  93041 


JACK  L  SMITHERMAN 
MERRITT  TOOL  CO,  INC 
CONTROLLER 
PO  BOX  1209 

KILGORE  TX  75662 


D  L  SMOCK 

NAVAL  SPRT  WPNS  CNTR 
WHITE  OAK  LAB 
SUP  GEN  ENGR 

SILVER  SPRING  MD  20910 


FRANCIS  R  SULLIVAN 
FORD  AEROSPACE 
TECH  PUBS  SUPR 
1572  NOKOMIS  DRIVE 
COLORADO  SPRNGS  CO  80915 


SUE  SWANSON 

TEXAS  INSTRUMENTS 

CONFIGURATION  MANAGER 

2012  PORTS  O'CALL 

PLANO  TX  75075 


K  M.  TAYLOR 
AT&T  CONSUMER  PRODUCTS 
DEPT  CHF-PUB ' G  SVCS  PLNG 
2400  REYNOLDA  ROAD 
WINSTON-SALEM  NC  27106 


WALTER  E  THIELE 

GENERAL  MOTORS 

SUPV.  DRAFTING 

6767  HOLISTER  AVE 

GOLETA  CA  93117 


RICHARD  C  THOMAS 
FMC  CORPORATION 
CONFIGURATION  MGR 
1105  COLEMAN  AVE,  BOX  1201 
SAN  JOSE  CA  95108 


RONALD  J  SCHRAGE 
US  AIR  FORCE 
DATA  MANAGEMENT  OFFICER 
ASD/XRJ 

WPAFB  OH  45433 


I  SHAPIRO 

H  D  LABS 

DELHD-IT-EA 

2800  POWDER  MILL  ROAD 

ADELPHI  MD  20783 


EDWARD  R.  SHOEMAKER,  JR 
PRATT  &  WHITNEY  AIRCRAFT 
CONFIGURATION  MANAGER 
PO  BOX  2691,  MS  709-64 
W.  PALM  BEACH  FL  33402 


HELEN  SMITH 

HUGHES  AIRCRAFT 

HD. ,  D/M  DATA  SUBMITTAL 

P.  0.  BOX  902,  BLDG  El,  MS  A169 

EL  SEGUNDO  CA  90245 


WILLIAM  L.  SMITHSON 

USA,  MICOM 

COMMANDER 

ATTN:  DRSMI-JTE 

REDSTONE  ARSNL  AL  35898 


R.  LEON  SNODGRASS 
E  G  &  G 
ENGINEER 

2150  FIELDS  ROAD 
ROCKVILLE  MD  20040 


RICHARD  H  SUSKIND 
LOCKHEED  MISSILES  &  SPACE 
SUPERVISOR  DOC  ENGINEERING 
2124 

AUSTIN  TX  78744 


MR  EDWIN  SWEETMAN 
THE  BEND  IX  CORPORATION 
NAVIGATION  &  CONTROL  DIV 
DEPT  9009  PLANT  1 
TETERBORO  NJ  07608 


FRED  G  TESSIER 
LITTON-INT'L  LASER  SYSTEMS 
DIRECTOR,  INFORMATION  SERVICES 
3404  N  ORANGE  BLOSSOM  TRAIL 
ORLANDO  FL  32804 


JULIE  A.  THOMAS 
TRW 

ASST  PRGM  MGR 

7600  COLSHIRE  DRIVE 

MCLEAN  VA  22102 


CHARLES  E.  TIEDEMANN 
MCDONNELL  DOUGLAS  ASTRO 
BLDG  101 /MEZ/200-1 14 
PO  BOX  516 

ST.  LOUIS  MO  63166 


ROBERT  1  TRAVIS 
MARTIN  MARIETTA  AEROSPACE 
MANAGER.  SYSTEMS  STANDARDS 
475  SCHOOL  STREET 
WASHINGTON  DC  20024 


JOY  L  VIARS 

DESIGNERS  S<  PLANNERS,  INC. 
SECTION  CHF-SPECS  GROUP 
1725  JEFF  DAVIS  HWY,  STE  700 
ARLINGTON  VA  22202 


H.  PETER  WEISS 

JNT  TACTICAL  COMM  OFFICE 

DATA  MANAGEMENT  SPECIALIST 

RUSSEL  HALi_  BLDG  286 

FORT  MONMOUTH  NJ  07703 


ALFRED  H.  WHITE 

ARINC  RESEARCH  CORP 

PRINCIPAL  ENGINEER 

4055  HANCOCK  STREET 

SAN  DIEGO  CA  92110 


LAMAR  E.  WILLIAMS,  JR 
NEWPORT  NEWS  SHIPBUILDING 
TECH.  PUB'S  SUPERVISOR  (E14) 
4101  WASHINGTON  AVENUE 
NEWPORT  NEWS  VA  23607 


DOUGLAS  A.  WILSON 

HUGHES  AIRCRAFT 

HEAD,  PROGRAM  CONTROLS 

PO  BOX  902  (BLDG  El,  E/S  A118) 

EL  SEGUNDO  CA  90045 


EUGENE  W.  WRIGHT 

TPC  LOGISTICS  SERVICES,  INC 

VICE  PRESIDENT,  ILS 

60  CHAPIN  ROAD 

PINEBROOK  NJ  07058 


DOUGLAS  A.  WILSON 

HUGHES  AIRCRAFT 

HEAD.  PROGRAM  CONTROLS 

PO  BOX  902  (BLDG  El,  E/S  A11B) 

EL  SEGUNDO  CA  90045 


BEECHER  W.  VAUGHN 
USAF/AEC 

DIRECTOR  OF  CONFIG.  MGMT 
ASD/AEC 

WPAFB  OH  45433 


CLIFFORD  G  WAYNE 
ELECTRONIC  *c  SUPP  SVCS,  INC 
EDITOR 

1128  107TH  STREE 
ARLINGTON  TX  76011 


WAYNE  H  WHEELER 
MOTOROLA  INC  G  E  D 
8201  EAST  MCDOWELL  ROAD 
P  0  BOX  1417  MAIL  DROP  1137 
SCOTTSDALE  AZ  85252 


MIKE  WILCOX 
MERRITT  TOOL  CO,  INC 
MANAGER  -  ENGINEERING 
PO  BOX  1209 

KILGORE  TX  75662 


ROLAND  D  WILLUWE IT 

USA  AVIONICS  R&D  ACTIVITY 

ELECTRONICS  ENGINEER 

ATTN  SAVAA-S/PE 

FT  MONMOUTH  NJ  07703 


EVERETT  A  WOODWARD 
HONEYWELL  MARINE  SYSTEMS  DIV 
ENG  'G  DOC/LOGISTICS  MGR 
5303  SHILSHOLE  AVE  NW 
SEATTLE  WA  98017 


GORDON  WYSOCKI 
*  HONEYWELL,  INC 
I  DATA  MANAGER 

13350  US  HWY  19  SO. 

!  CLEARWATER  FL  33546 


EVERETT  A  WOODWARD 
HONEYWELL  MARINE  SYSTEMS  DIV 
ENG 'G  DOC/LOGISTICS  MGR 
5303  SHILSHOLE  AVE  NW 
SEATTLE  WA  98017 
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